ANFS 4.18 for the Model B

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
User avatar
Lardo Boffin
Posts: 1612
Joined: Thu Aug 06, 2015 6:47 am
Contact:

ANFS 4.18 for the Model B

Post by Lardo Boffin » Sun Jul 14, 2019 7:38 am

I got the enhanced ANFS 4.18 ROM in my latest econet kit from Beebmaster as he said it runs a bit faster and has extra tools etc.
So I thought I would give it a go with some simple time tests. I repeated each test a couple of times and got the same results.

First I did an *DUMP of a 16K ROM image (BCPL) on the Master that runs my econet (using DFS). It has a Retroclinic DC and CF card HD and is running the Retroclinic internal pi co processor (the faster one, rather than the one that runs Elite at a playable speed).
This took 35 seconds to dump the whole file to screen in mode 7.

Then I did the same in DFS with a gotek attached to a model B (no co-proc) and it took 39 seconds for the same file. This was a surprise. I thought it would be much slower than the CF card. I tried it with a co-proc attached and it made no difference (I guess as it is mainly I/O that makes sense).

Then I tried with the standard DNFS ROM in the model B and the dump took 5 minutes and 2 seconds! The model B is attached to the Master (now running as an econet server) that I used above.

With the ANFS ROM in place on the model B it took 29 seconds! Faster than the DFS dump on the master it is connected to!

I guess the conclusion from this is that *DUMP in the ANFS 2.18 ROM is a really good implementation of the program, presumably better than the DFS running on the Master etc.

I will try and see if it is any faster / slower compiling C using the Norcroft compiler on the ARM Eval co-proc once I get it working over the econet.
Atom, issue 5
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
USA Model B
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

User avatar
jgharston
Posts: 3596
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: ANFS 4.18 for the Model B

Post by jgharston » Sun Jul 14, 2019 12:47 pm

It's not *DUMP, it's the channel buffering, you'd see exactly the same thing if you did it on BASIC.

*DUMP essentially does:
REPEAT
A%=BGET#in%
PRINT stuff
UNTIL EOF#in%

NFS has no buffering, so whenever you fetch a single byte a whole network transaction has to happen.
Hello server, are you there? Yes I am. I want a byte from this channel. Here it is.
About 40 network bytes per byte transfered.

ANFS buffers open files, so whenever you fetch a single byte ANFS first looks in the local buffers, and if they are empty fetches 256 bytes all in one go.
if (ptr AND 255)=0 then
Hello server, are you there? Yes I am. I want 256 bytes from this channel. Here they are.
endif
get byte from local buffer, increment ptr
About 292 network bytes per 256 bytes transfered, so about 1.14 network bytes per byte

Other buffered filing systems do the same thing, disk systems because disk data comes in chunks of whole sectors, BBC tape because tape files becomes in chunks of whole blocks. When you fetch a single byte you have to load an entire block into memory and then fetch bytes from that block in memory. Depending on the hardware overhead, fetching a block into memory may be faster or slower than other filing systems; fetching a byte from that buffered block in memory will tend to be the same speed on any filing system as it's just fetching from memory.

SJ supplied network-specific DUMP and TYPE utilities loaded from disk that were written to themselves use local buffering using OSGBPB. After all, if you're displaying lines of eight bytes, you may as well fetch eight bytes all in one go. The buffering efficiency rises very rapidly, even fetching two bytes at a time doubles throughput*.

The ROM-based DUMP and TYPE have to use BGET and rely on any buffering provided by the filing system as BGET is the only guranteed data read call. Some filing systems such as TAPE and ROM do not provide OSGBPB. The Master provides a vener over TAPE and ROM to provide a subset of OSGBPB.

*A quick table of buffering efficiency:

Code: Select all

 bytes   network   net/    speed
fetched   bytes    data
   1       41       41      x1
   2       42       21      x1.9
   3       43       14.3    x2.9
   4       44       11      x3.7
   5       45        9      x4.6
   6       46        7.6    x5.4
   7       47        6.7    x6.1
   8       48        8      x5.1
   9       49        5.4    x7.6
  10       50        5      x8.2
  20       60        3      x14
  50       90        1.8    x23
 100      140        1.4    x30

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
BeebMaster
Posts: 2775
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: ANFS 4.18 for the Model B

Post by BeebMaster » Sun Jul 14, 2019 1:54 pm

As well as the speed increase with certain operations as already mentioned, ANFS has many more commands in ROM than NFS. One example is *FS, which returns or selects the file server number. So with ANFS on a Model B you can easily switch between two logged-on servers instead of having to go through a *I AM process every time, and losing your context (unless you have a Library *FS utility of course).
Image

Post Reply