I was a little over-eager to declare victory. While it does now keep
transmitting packets (and getting return acks for the missing segment), the
time required to retransmit the missing packet is still about 26 seconds.
cubic vs. reno doesn't seem to matter much either.
JK
--- In "ocean_research_jk" <> wrote:
>
> In order to fix this problem, I added the following onto the end of the
> /etc/sysctl.conf file. I don't know if all of them are necessary, but it
> takes a long time to test one by one, waiting for a lost packet and looking
> through tcpdumps. Without the tcp_frto change, it was down to a 26 second
> pause, and now it just waits for about 40 retransmit requests (still odd),
> then sends the lost packet immediately.
>
> net.ipv4.tcp_rmem= 131072 524280 3145728
> net.ipv4.tcp_wmem= 131072 1440000 3145728
> net.ipv4.tcp_mem= 3145728 3145728 8388608
> net.core.wmem_max=3145728
> net.core.rmem_max=3145728
> net.core.rmem_default=196608
> net.core.wmem_default=196608
> net.core.optmem_max = 1800000
> net.ipv4.tcp_retrans_collapse = 0
> net.ipv4.tcp_slow_start_after_idle = 0
> net.ipv4.tcp_frto = 0
> net.ipv4.tcp_congestion_control = cubic
>
> JK
>
> --- In "naturalwatt" <martin@> wrote:
> >
> >
> >
> > --- In "ocean_research_jk" <jonathan.klay@> wrote:
> > >
> > > I've been struggling all week with this issue. I have a few instruments
> > > connected on serial ports. I collect the incoming data and pump it out on
> > > a tcp port. When there is a packet lost. I see something like this
> > > (although it varies)-
> > > packet1
> > > ack for 2
> > > packet2
> > > ack for 3
> > > packet4
> > > ack for 3 (DUP)
> > > (slight pause)
> > > packet5 (full size)
> > > ack for 3 (DUP)
> > > packet6 (full size)
> > > ack for 3 (DUP)
> > >
> > > (pause for 3 to 10 minutes)
> > >
> > > packet3
> > >
> > > This long long delay really bogs down the system. I've tried changing
> > > some tcp setting like window_scaling, sack, etc. The only improvement
> > > was to up the buffer memory, which keeps the connection from getting
> > > dropped in some instances, depending on how many segments get lost. Any
> > > idea how to get a quicker retransmit?
> > >
> >
> >
> > There were some posts on here, some I think from Technologic staff, about
> > network problems on the TS7500/7550 series. It is do with the built in
> > NIC, apparently, it keeps deconfiguring itself. The Technologic guy said
> > that they had been working with the chip vendor and tried lots of
> > documented and undocumented internal settings to no avail.
> >
> > So please feel free to address Technologic directly to ask if they are
> > making progress on this problem.
> >
> > Martin
> >
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|