Re: [Sheflug] [OT, slightly] Parallel port network interfaces?

["Chris J/#6" <nospam [at] nccnet.co.uk>]

> 
> Whatever is reporting the transfer is stuffing the data in a buffer,
> then waiting until the buffer is empty, reporting the whole transfer
> as if it was instantaneous, and then repeating.
> 

Standard command line ftp with hash mark printing on, and me checking the 
file progress typing "ls -l <file>" every now and then. I could understand if 
the bursts were such that it gave a decent xfer speed, but it's 0.7k/sec or 
thereabouts. As I said - switching all PPP compression options off boost 
performance quite a chunk (to 2k/sec or faster).

It's something deep at the protocol level I think ... there's no reason why 
FTP should act differently with or without PPP compression. I also don't know 
whereabouts the delay is being introduced ... PPP on the laptop [Linux], PPP 
on the Sun [OpenBSD], which is acting as a router for the laptop so I can 
talk to the FTP server [Proftpd] on my main machine [Linux].

I've thrown tcpdump on the link to see what's going on and at those delays 
absolultely no traffic passes between the machines. That burst comes, gets 
written to disk, then for some reason, either proftpd or the network 
protocols just decide to stop traffic for a couple of minutes or so.

I'm not convinced its as simple as a buffer in the FTP client.

Chris...


-- 
@}-,'--------------------------------------------------  Chris Johnson --'-{ [at] 
    / "If not for me then, do it for yourself.  /   sixie [at] nccnet.co.uk    \
   / If not for me, then do it for the world"  /  www.nccnet.co.uk/~sixie  \ 
  /                          -- Stevie Nicks  /                             \


---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.