This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Packet loss/performance with 5.204

Up until this morning, I had happily been running V4 for years. This week I up'd my cablemodem connection to get a static IP and real speeds.
Ever since, I'd been noticing "lags" when doing anything online (ssh/http basically). VPN would drop in out on a consistent basis after only a few minutes, or even seconds, of being connected from my OSX 10.4 laptop (behind the f/w) into an Astaro 5 f/w at work.

I spent last nite digging into pings and traceroutes. Eventually found out that pings going out of Astaro were 'stalling'. There'd be a minute or two of 7-12ms pings, then it'd jump to 1-5 1000++ms pings. 

I determined that's the lag I was experiencing. So I hopped on this board, and google, and started reading. With v4 the shell seemed like it lacked some commands, so I looked up the h/w HCL for v5. 

My machine should fit the bill. It's a leftover PC, Dell Optiplex gx1p PIII 700MHz with 768MB ram and an ide drive. One 10/100 nic on the motherboard:

Aug  9 09:05:28 (none) kernel: 00:11.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xcc00. Vers LK1.1.16
Aug  9 09:05:28 (none) kernel: [MAC ADDRESS], IRQ 11
Aug  9 09:05:28 (none) kernel: product code 4920 rev 00.9 date 07-03-97
Aug  9 09:05:28 (none) kernel: Internal config register is 1800000, transceivers 0xa.
Aug  9 09:05:28 (none) kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
Aug  9 09:05:28 (none) kernel: MII transceiver found at address 24, status 786d.
Aug  9 09:05:28 (none) kernel: Enabling bus-master transmits and whole-frame receives.
Aug  9 09:05:28 (none) kernel: 00:11.0: scatter/gather enabled. h/w checksums enabled

which is eth0, to the internal lan.

The second NIC is an Intel Pro 100 Dual:

Aug  9 09:05:28 (none) kernel: Intel(R) PRO/100 Network Driver - version 2.3.27
Aug  9 09:05:28 (none) kernel: Copyright (c) 2003 Intel Corporation
Aug  9 09:05:28 (none) kernel: 
Aug  9 09:05:28 (none) kernel: e100: selftest OK.
Aug  9 09:05:29 (none) kernel: e100: eth1: Intel(R) PRO/100 Network Connection
Aug  9 09:05:29 (none) kernel: 
Aug  9 09:05:29 (none) kernel: e100: selftest OK.
Aug  9 09:05:33 (none) kernel: e100: eth2: Intel(R) PRO/100 Network Connection

Both seemed to be OK as far as the HCL was concerned. I searched this message board for "Intel Pro" and found people asking about VLAN's with it, but I could not find any complaints.

So out of desperation I looked up how to upgrade my home license, upgraded it, grabbed the 5.204 ISO, burnt it. Backed up my current V4 config. Booted the cd. Did the initial install. It wouldn't take the V4 config. (Sorry, I forgot to note the exact error message). Since this is my house, and I'm not doing anything extravagent, no biggie. I just re-created everything from scratch.

Basically: eth0 to 192.x.y.z lan inside the house.
Dnat_ and s_nat to a linux machine so I can ssh in. 
Masq_out for the internal lan.

Everything seemed great. The http v5 interface is somewhat slower then v4, but it does a heck of a lot more, and I'm used to that since I upgraded both our f/w's at work to v5 last year.

So I started testing. Pinging on the internal lan is all 0.xxx ms. Nice and quick (gigabit w/ an elcheapo few-port gb switch). 
However, traffic going through the outbound nic is once again lagging:

64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=49 ttl=58 time=7.91 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=50 ttl=58 time=9.44 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=51 ttl=58 time=8.93 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=69 ttl=58 time=686 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=70 ttl=58 time=8.19 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=71 ttl=58 time=8.68 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=72 ttl=58 time=9.23 ms
....
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=105 ttl=58 time=9.91 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=121 ttl=58 time=365 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=122 ttl=58 time=15.3 ms
---
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=133 ttl=58 time=8.78 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=143 ttl=58 time=299 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=144 ttl=58 time=7.90 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=145 ttl=58 time=9.80 ms
...
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=179 ttl=58 time=11.8 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=210 ttl=58 time=648 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=211 ttl=58 time=9.68 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=212 ttl=58 time=8.94 ms
...
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=292 ttl=58 time=1103 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=293 ttl=58 time=111 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=294 ttl=58 time=8.30 ms
---
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=440 ttl=58 time=7.69 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=493 ttl=58 time=742 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=494 ttl=58 time=8.68 ms
64 bytes from machine-on-fiber (w.x.y.z): icmp_seq=495 ttl=58 time=9.07 ms

153 packets transmitted, 153 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.118/0.182/0.477/0.041 ms

I'm pinging a machine at the office that is on Fiber direct from the ISP, it is known to have excellent bandwidth. It is only 4 hops away from my home network (same ISP, Time Warner Cable).

My original thoughts were that the PIII was just too slow, or that V4, since it was so old, might've had some problems here or there, so it was probably a good idea to upgrade, and that would fix this problem.

Where it gets interesting is that if I pull the Astaro machine out of the loop, and put my laptop in it's place, I do not see any latency issues, and the ping times are all in the 7-12ms for as long as I let it run.

That leads me to believe that the problem is my Astaro machine. Could it be hardware? I loooked at the boot.log, didn't see anything out of ordinary.

However, I do not have, at this time, httpd proxy on (I normally use it, in transparent mode). DNS proxy, and DHCP. That's it. Nothing else is used. Looking at hardware-reporting shows:

cpu 15 minute average: current: 0.11 average: 537.74 m max: 1.26
memory: (averages) used: 125M free: 649M total: 774M
swap: (averages) used: 14.30k free: 1.53G total: 1.53G
/var/log and /var/storage are empty, since the machine's only been running for a few hours this morning.

Where it is really interesting is this. If I put my laptop on the 2nd port of the cablemodem (so it is alongside astaro, not behind it), then remove my 2nd IP address from Astaro and give it to the laptop, I can start simultaneously pinging an outside machine from both the laptop, and any machine that is behind the Astaro. And guess what? 400-1000ms ping times on the box on the inside, 7-12 ms ping times on the laptop that's not behind Astaro.

My only options at this point, it seems are:

1) reconfigure the network stac on the astaro machine so that the eth0, which is on the motherboard, is not used. (the intel pro is a dual-port card)
2) replace the intel pro and see if it helps (ugh, $)
3) upgrade to Astaro v6
4) build a new machine that is quicker.

I would appreciate any advice anyone can give me. Even trying to post this, the browser's timing out, it's very frustrating, ("The host you are trying to send the input from is not a valid host." ugh) and yet even more frustrating when ssh'ing into machines at the office and waiting seemingly minutes to see what's going on.

Thanks,
 Shane


This thread was automatically locked due to age.
Parents
  • Run TOP on ASL while your doing the pings and see if there's any correlation with high CPU use.

    Also, see if the disk is busy at the same times.

    Barry
  • It doesn't seem to be correlated to the CPU. While I was seeing this:

    64 bytes from {ipaddress}: icmp_seq=19 ttl=58 time=2265.736 ms
    64 bytes from {ipaddress}: icmp_seq=20 ttl=58 time=1270.041 ms
    64 bytes from {ipaddress}: icmp_seq=21 ttl=58 time=274.430 ms
    64 bytes from {ipaddress}: icmp_seq=22 ttl=58 time=8.930 ms
    64 bytes from {ipaddress}: icmp_seq=23 ttl=58 time=12.903 ms
    64 bytes from {ipaddress}: icmp_seq=24 ttl=58 time=11.186 ms

    top never really fluctuated from this:

    top - 17:10:25 up  8:05,  2 users,  load average: 0.43, 0.28, 0.17Tasks:  67 total,   2 running,  63 sleeping,   0 stopped,   2 zombie
    Cpu(s):   0.3% user,   0.3% system,   0.0% nice,  99.3% idle
    Mem:    774612k total,   305896k used,   468716k free,    74412k buffers
    Swap:  1551952k total,        0k used,  1551952k free,   126472k cached

    selfmonng.pl and confd did seem to pop up at the top of the 'top' output when the pings were running through, however. I don't know what either are/do.

    What I did find interesting was the disk activity. When the pings paused, I could count to 7 - by saying 1001...1002...7 and then the disk light would flash for about 1.5 seconds. I could do that anywhere from 1-5 times, during a pause.

    When the ping wasn't happening, the light for the drive flickers about every 8 seconds, but it's real quick.

    Does that help at all? Please tell me it does! 

    Thanks,
     Shane
  • SCSI or IDE drive?
    if IDE, post the results of
    hdparm /dev/hda

    (That'll show if DMA is enabled.)

    Barry
Reply Children
  • It's ide. It seems as though dma's on:

    host:/home/login # hdparm /dev/hda

    /dev/hda:
     multcount    = 16 (on)
     IO_support   =  0 (default 16-bit)
     unmaskirq    =  0 (off)
     using_dma    =  1 (on)
     keepsettings =  0 (off)
     readonly     =  0 (off)
     readahead    =  8 (on)
     geometry     = 1244/255/63, sectors = 19999728, start = 0
  • Astaro does a lot of writes to the disk, but it _shouldn't_ cause any problems.

    FWIW, your computer is faster than what I'm using at home with a 4mb/512k Cable modem, and I don't have any problems like that (and I do full accounting).

    If you have different motherboard or computer around, try it.
    See if there's a newer BIOS for your Dell.

    Meanwhile, you could turn off accounting if it's on... that might help a little.

    Barry
  • Disabling DMA might be worth a shot, although it probably will be slower...

    IIRC, you can change it with HDParm, but there is a chance of data corruption.

    Supposedly ASL 6 is faster, btw.

    Barry