T.R | Title | User | Personal Name | Date | Lines |
---|
359.1 | An hour is great!!!! | KIRK::LONG | | Fri Feb 27 1987 13:55 | 9 |
| The protocol transfer is doing more than just the sending of
a stream of bytes, between the hand shaking, the packet
verification, buffering, and transfer to disk which aren't
taking place in parallel. All in all, a little over an hour
is not bad considering it took me over 3 hours with KERMIT
at 1200 baud to get Juggler.
Maybe my cost center will put an E-net drop into my house ;^)
|
359.2 | Sounds okay ... | AUTHOR::MACDONALD | WA1OMM Listening 224.64 | Fri Feb 27 1987 14:16 | 6 |
| XMODEM tends to be much faster than KERMIT.
At 2400 baud, you must be dialing direct to your system since TSN
doesn't seem to support 2400 baud yet. An hour sounds about right.
Try downloading it from a commercial network such as CIS. You'll
be there all night!
|
359.3 | | TLE::RMEYERS | Randy Meyers | Fri Feb 27 1987 16:09 | 9 |
| A nit about the calculations in .0:
It takes a modem 10 bits to send 8 data bits. There is a start and stop
bit used. Thus, 300 baud equals 30 eight characters per second.
But, as the previous replies state, most of the time goes towards protocol
overhead. I haven't looked at the XMODEM or Kermit protocols, but it is
not that unusual to find that the protocol increases the number of bytes
shipped through the modem by 50% to 100%.
|
359.4 | New Calculations | SQM::JMSYNGE | James M Synge, VMS Performance Anal. | Fri Feb 27 1987 20:36 | 26 |
|
I came across an interesting analysis of line usage in the
Kermit Protocol Specs. I'll try to restate it accurately.
One of the key things which can slow down a transfer is the
circuit delay. You can probably include the time it takes
to formulate and decode a packet in this.
If you have a 300 baud line, and a 1 second delay, then sending
a packet of 100 bytes and receiving the ack would take 4.3 seconds.
That is approx. 230 baud.
For a 1200 baud line, sending the packet would require .83 seconds.
Adding the time for the ack (1 second), we get an effective rate
of 545 baud.
Finally, for the 2400 baud line, the total time required would
be 1.42 seconds. 705 baud would be achieved.
As a result of this argument, Kermit was changed to optionally
include sliding windows (multiple packets can be sent before
needing an ack) and long packets (over 1000 I believe).
When to use them depends on you line quality and ciruit latency.
James Synge.
|
359.5 | I agree. Too Slow! | HOUSE::FRACTAL | | Fri Feb 27 1987 21:07 | 9 |
| What do all you guys keep your df224 set at, I left mine at 11
character bits and 1 stop bit. My software is set at 2 stop bits
and 8 bits. Will this create a problem (I have been having trouble
downloading) Everything I download with arc has a bad header. Somewhow
though i managed to download arc.bin using xmodem binary but every
other arc file gets all screwed up-is this the problem?
reply .1
I agree kermit is unrealisticly slow when downloading anything.
|
359.6 | | AUTHOR::MACDONALD | WA1OMM Listening 224.64 | Sat Feb 28 1987 10:27 | 3 |
| The ONLY parameters you should be fiddling with on the 224 are
BAUD and PARITY (none or even). Don't futz around with anything
else. The remaining settings are normal.
|