🚀 go-pugleaf

In article <911202398snz@isis.demon.co.uk>
           ian@isis.demon.co.uk "Ian Smith" writes:
[..]
> I haven't got round to looking at the code yet and I can't test any of 
> it, but here's an initial theory which assumes fast (200+Mhz clock) 
> hardware and a buffered COM port with a big buffer. With a small file, 
> less than the buffer size, KA9Q could see an essentially instantaneous 
> transfer and, more ominously, a zero transfer time. When it tries to 
> calculate the rate...

Check for a zero divisor before calculating the rate?  I don't
have the YAN source on tap to check, but the GremNOS source
(which I understand is a close relative) has such a check in
the places I looked.  Should be a simple thing to check, and
either fix or eliminate from enquiries.

> The second scenario is easily tested by seeing how the hash or no 
> progress display gets on with files bigger than the COM port buffer.
> The first might be suggested if very small files blow it while big files 
> don't.
> Dunno if any of this holds water, but when I woke up this morning it 
> looked bloody plausible :)

If all else fails, that would make a great lyric for some
blues ;-)

> Maybe I need more sleep.
> And to get out more.

C'mon - if we all did that there'd be no usenet...
-- 
Pete
        "We have not inherited the earth from our ancestors,
         we have borrowed it from our descendants."