Antoine, maybe this isn`t a networking problem but a problem with the UML process itself ? Keep in mind that a UML is a program which runs in userspace - and it`s no realtime application. So, under certain circumstances the response of that application probably could be slower than normal - e.g. when paging/swapping occurs.
You probably could try,if the mlock patch fixes your problem - perhaps have a look at: http://sourceforge.net/mailarchive/message.php?msg_id=8546589 for that. I don`t think , that this is a "routing" problem. regards Roland ----- Original Message ----- From: "Antoine Martin" <[EMAIL PROTECTED]> To: "User Mode Linux User" <[EMAIL PROTECTED]> Sent: Thursday, December 16, 2004 7:53 PM Subject: [uml-user] re: peculiar intermittent network seizures with uml-2.4.27-1 on 2.4.28 > > Notably, the UML ceases responding to network packets for up to a minute > > and a half at a time, then restarts again just as quietly: the > > console-on-network-port freezes at the same time. The UML continues > > running and packets get queued on either side of the... blockage, and > > are allowed through when it lifts. > > > > Example, pinging every five seconds (this one happened to be a fairly > > short blockage): > > > > 64 bytes from 192.168.14.1: icmp_seq=57 ttl=64 time=1.1 ms > > 64 bytes from 192.168.14.1: icmp_seq=58 ttl=64 time=1.3 ms > > 64 bytes from 192.168.14.1: icmp_seq=59 ttl=64 time=1.3 ms > > 64 bytes from 192.168.14.1: icmp_seq=60 ttl=64 time=1.3 ms > > 64 bytes from 192.168.14.1: icmp_seq=61 ttl=64 time=7993.1 ms > > 64 bytes from 192.168.14.1: icmp_seq=62 ttl=64 time=14206.3 ms > > 64 bytes from 192.168.14.1: icmp_seq=63 ttl=64 time=9219.6 ms > > 64 bytes from 192.168.14.1: icmp_seq=64 ttl=64 time=4219.6 ms > > 64 bytes from 192.168.14.1: icmp_seq=65 ttl=64 time=1.3 ms > > > > The blockages happen quite intermittently, but I'd estimate the mean > > time between blockages to be about ten minutes. > > > > The UML has two network interfaces, both bridged tun/tap interfaces: the > > one I'm pinging down here, and another, bridged to an ADSL router, > > traffic-shaped, and firewalled with iptables. > > > > (This may be an iptables bug: I'll build a UML without iptables and with > > only one interface tonight, and see if the problem still occurs.) > > > > > > Anyone seen anything like this before? Any suggestions as to how I might > > debug it? > I've had similar issues before. > Looks to me like this is a routing problem, check your arp tables and > your routes. It may be that something is occasionally causing a packet > to come out of the wrong interface/wrong mac, which confuses the lower > network layers. > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > User-mode-linux-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ User-mode-linux-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
