kajifk@TERMIX.TERMO.UNIT.NO (Kjell Arne Jacobsen) (11/15/90)
I m currently running CAP (uab, atis and aufs) at our VAX 3200 running Ultrix 4.0. It is stable and is functionality is as described in the documentation of the CAP software. However, there are one nag... writing to the Aufs volumes are really slow. This confuses me beacuse reading data from the same discs is pretty fast (something between a internal floppy and hard disk). There are two bridges in our local area; one AlisaShare bridge and one Gatorbox. They are both connected to the fast ethernet cable, however the communication to the Gatorbox has to go through a 64 Bits/sec. bridge (it is one a remote ethernet segment). The latter could parhaps be an explanation for the slow write transfer but not the "fast" read transfer. Is there anyone able to give me an explanation on this phenomenon? I would be glad to know....
tom@wcc.oz (Tom Evans) (11/18/90)
In article <9011150910.AA15548@termix.termo.unit.no>, kajifk@TERMIX.TERMO.UNIT.NO (Kjell Arne Jacobsen) writes: > I m currently running CAP (uab, atis and aufs) at our VAX 3200 running > Ultrix 4.0... However, there are one nag... writing to > the Aufs volumes are really slow. This confuses me beacuse reading data > from the same discs is pretty fast... > ...however the > communication to the Gatorbox has to go through a 64 Bits/sec. bridge It's probably the bridge, combined with a "non-standard" default in AUFS. Here's what is happening: Mac starts up a session with AUFS, and as part of the startup bounces a max-length AppleTalk echo packet to see how fast the line is. It will take about .02s on LocalTalk and about 0.08s on the bridge going and the same coming back. Add in a bit of computer/router delay and it will take about 0.25s. The Mac doubles this (this is a known bug - it should multiply it by 4), gets 0.5s, notices it is less than 2.0s, so sets its ATP retry delay to 2 seconds. Neat huh? AUFS starts up a session with the Mac and assumes a 1 second timeout. Primitive huh? Mac goes to read data from AUFS. It sends an ATP TREQ (request) asking for 8 packets and starts counting. They take about 0.13 seconds each and are all in in about 1.04 seconds. Mac goes to write data to AUFS. It sends a command up that causes an ATP TREQ to be sent back. The Mac then sends the 8 packets up to AUFS, but AUF's 1 second timer goes off before all the packets are counted back in, so it asks for the one(s) it hasn't got yet. The Mac then has to send it/them again and you've lost throughput for no good reason. Any other delays on the system (I've assumed fairly optimal timing) or any other Macs pushing data through your 64k line at the same time should cause a bad blowout. The Mac-->AUFS direction has about 1 seconds worth of slack (about 100%). The Mac<--AUFS has about -5%. Writes from Macs to AUFS look to be handled by "SPWrtContinue()" calls in afpfork.c and afpdt.c, which have "-1" as their timeout value. In abasp.c, the "SPWrtContinue()" code has in it: ap->atpTimeout = atptimeout <= 0 ? 4 : atptimeout /* make it */ /* one second if no value specified */ This code is getting passed "-1", so it is using a "default" 1 second timeout (1/4 second ticks). Bump this up to "8" and see if it gets better. Please let me (us all?) know if it works - I haven't tried it. ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179
dunlop@wateol (Doug Dunlop) (11/19/90)
In article <9011150910.AA15548@termix.termo.unit.no> kajifk@TERMIX.TERMO.UNIT.NO (Kjell Arne Jacobsen) writes: >I m currently running CAP (uab, atis and aufs) at our VAX 3200 running >Ultrix 4.0. It is stable and is functionality is as described in the >documentation of the CAP software. However, there are one nag... writing to >the Aufs volumes are really slow. This confuses me beacuse reading data >from the same discs is pretty fast (something between a internal floppy and >hard disk). > >There are two bridges in our local area; one AlisaShare bridge and one >Gatorbox. They are both connected to the fast ethernet cable, however the >communication to the Gatorbox has to go through a 64 Bits/sec. bridge (it >is one a remote ethernet segment). The latter could parhaps be an >explanation for the slow write transfer but not the "fast" read transfer. > >Is there anyone able to give me an explanation on this phenomenon? I would >be glad to know.... I noticed that there is quite a speed difference between CAP/Aufs on a Sun and a Vax. I think that the reason is due to the native byte ordering of the two machines. The Sun uses the network order as its native order while the Vax must byte swap. If anyone knows the details of this then please post. ============================================================================ | //===== //===// // | Doug Dunlop (Research Scientist) | | // // // // | Earth Observations Lab | | //=== // // // | University of Waterloo | | // // // // | (519) 885-1211 x2689 FAX 888-6768 | | //===== //===// //===== | dunlop@wateol.uwaterloo.ca | ============================================================================ --