Re: TCP problems after 124 days of uptime?

Andre Oppermann wrote:
Gleb Smirnoff wrote:
Yesterday two of our web servers running 6.2-PRERELEASE experienced
problems with accepting TCP connections. A small percentage of SYN
packets was ignored. The packets were seen in tcpdump output, but not
processed by TCP stack. No accept queue overflows occured, according
to 'netstat -sp tcp'.

Failing to find any clue I have rebooted one of them, and after
reboot is started to work flawlessly. Reboot also helped the second
one. Both servers were booted at the same time - 124 days ago.

Any ideas, any similar reports?

ticks is a 32 bit signed integer and TCP isn't really aware of it
going negative and rolling over. This is something I'm working on
fixing in -current. Haven't analyzed all potential cases there yet.


124 days is 32 bits at 400Hz
or 30 bits at 100Hz

what is the granularity of the TCP timer?

_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
    (comp.lang.perl.misc)
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
    ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
    (freebsd-performance)
  • Re: UDP vs TCP
    ... TCP for instance will break up a large packet into smaller ... into the packets and then the receiving app would have to read ... Network Layer -> ethernet ... DOMAIN over port 53 ...
    (microsoft.public.vb.enterprise)