Checked the duplex and both were auto. Set both to full and still have the same 
problem. (HP server w/Intel NIC, Cisco switch).

Any one else have any ideas?

Adam

> 
> From: Henrik Nordstrom <[EMAIL PROTECTED]>
> Date: 2005/02/10 Thu PM 07:17:31 EST
> To: [EMAIL PROTECTED]
> CC: [email protected]
> Subject: Re: [squid-users] Slow file download / read_timeout
> 
> On Thu, 10 Feb 2005 [EMAIL PROTECTED] wrote:
> 
> > I have a problem that I cant seem to figure out, hopefully somone can help.
> >
> > I have a single proxy server which does not cache and all users are forced 
> > to
> > go through for internet access. A few users have to download msword, excel 
> > and
> > other random files from several remote webservers (different networks,
> > operating systems, basically nothing in common remotely). It seems that when
> > users download txt files there is not a problem but when downloading a 
> > msword doc
> > (or other) it takes 15 minutes to completet the action. The files are not 
> > large, under 100kb, so it is like the download does not start for 15 
> > minutes. It is always the same time so I
> > looked for this value in the squid.conf and found read_timeout. Changing 
> > this
> > from default 15 minutes to 1 minutes allowed the docs to download in 1 min. 
> > I thought I was on to
> > something, but there really must be a better way. I looked at the mime.conf
> > thinking maybe it was something there but all looks good and in the logs 
> > squid is logging the proper mime type.
> 
> 
> Setting read_timeout low will cause Squid to terminate the request when 
> the read_timeout expires. If nothing at all has been received yet the 
> request will be automatically retried.
> 
> This indicates if anything that there is a network level problem causing 
> this kinds of requests to get stuck, quite likely dependent on how fast 
> the remote server returns the response.
> 
> First thing to verify is that your proxy server and the switch agrees on 
> the port speed and duplex. Things will behave very erraticly if there is 
> an disagreement.
> 
> Regards
> Henrik
> 


Reply via email to