🚀 go-pugleaf

In article <911130895snz@isis.demon.co.uk>
           ian@isis.demon.co.uk "Ian Smith" wrote:

>Is there a known problem with KA9Q's FTP when running in a DOS box under 
>Win95 ? 

Not known by me - that's how I run YAN...

>I've had two reports of spectacular failure when using the PUT 
>command from YAN, but under DRDOS the same code is flawless. I gather 
>that it doesn't happen with every file, but more often than not, which
>suggests a timing problem.

How 'spectacular'?  I mean, is this a blow-up which crashes the machine,
or something like the files just not being put properly which shows up
later?

Chris C

On Sunday, in article <911172839snz@alquds.demon.co.uk>
     News01@alquds.demon.co.uk "Shakib Otaqui" wrote:

>     Ian's question, in a private email, about Windows possibly 
>     buffering the port and upsetting the timing prompted some 
>     tests.  Ever since Win 3.x days, I've had "com2buffer=16384" 
>     in the [386Enh] section of system.ini.  It has enabled me to 
>     put a DOS comms session in the background and use fairly CPU-
>     and disk-intensive tasks in the foreground with hardly any 
>     hardware overruns -- in fact, the only way I've found to get 
>     them is to use Windows mark/copy in a DOS window, which seems 
>     to hog the machine.
> 
>     I tried the PUT command after commenting out the com2buffer 
>     line and rebooting and it worked fine.  I put it back with a 
>     1024-byte buffer and Yan blew up as before, so it does look 
>     as if buffering is the problem here.

Thanks for that.

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...

YAN, using it's bytecout progress display, might get similar problems 
with any file. Even on my paltry hardware I've seen initial progress 
rates around 100k/sec. With a bigger buffer and especially if the file 
was sitting in a disk cache it could push the laws of physics :)

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 :)
Maybe I need more sleep.
And to get out more.

Ian.
-- 
  |  Ian Smith             |  "The Moving Finger writes;
  |  ian@isis.demon.co.uk  |   and, having writ, Moves on."

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."

On Monday, in article <911248505snz@pdlmail.demon.co.uk>
     pete$no$pam@pdlmail.demon.co.uk wrote:

> 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.

Yes, all the KA9Qs I've looked at have such a check (even YAN :), but 
this little bug(ger) was all my own work. The running transfer rate 
calculation in the bytecount progress display didn't check :(  Yet 
another casual doodle come back to haunt me :(

I'm still impressed that it ever hit though, but I must admit that the 
effect of a large COM buffer didn't enter my calculations (such as they 
were).

Ian.
-- 
  |  Ian Smith             |  "The Moving Finger writes;
  |  ian@isis.demon.co.uk  |   and, having writ, Moves on."

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...

You also need to be aware that under '3.1 or '95, KA9Q can see the 
time go backwards as well as forwards - this is due to it trying to 
read the downcount in the 8254 to get a more accurate view of the time 
- under Windoze, the timer interrupts don't correspond to the reset of 
this count (well they do but not by the time KA9Q gets them), so using 
the two in conjuction gives values which can jump backwards.

I have some code to fix it but it requires a 386 clean version of KA9Q
since the Windows calls needed return values in 32-bit registers.
(Turning isat off probably also fixes it but at the expense of a
higher granularity in timing).

Cheers, Graham.
-- 
Graham E. Kinns -------------------------- <Graham@grempc.demon.co.uk>
"I've done many things that have gotten very popular but amongst a
 sorta nerdy community ... because the kinda stuff I do is stuff that
 I have no idea how to explain it to my mom" - James Gosling.