Guest User!

You are not Sophos Staff.

[7.902][QUESTION][ANSWERED] Vlan Slow

Hi all 

i have an

eth1 [Intel Corporation 82541PI Gigabit Ethernet Controller]
Auto negotiation: On
Supported link modes: 10baseT/Full,10baseT/Half,100baseT/Full,100baseT/Half,1000baseT/Full
MAC Address: *********
Interrupt (IRQ): 17
PCI Device ID: 0x107c:0x1376
MII capable: No
HA link monitoring: No



on asg 7.902 and on this nic i have 4 vlans enabled 1 disabled

if i copy from one vlan to an other (50 to 60 ) i only get 42Mbps data transfer rate 
if i copy from  vlan 50 to vlan 50 data transfer is ok 

Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
        Link detected: yes


has anyone an idea why transfer over astaros gigabit nic is soo slow 
it is connected to an netgear gs108T gigabit switch 
thanks for info / help
  • Please check Astaro's CPU graphs during the tests.

    Barry


    Hi  

    test with ips on: 

    after some time of transfer 
      

    near the end of transfer 


    test with ips off:

    after some time of transfer 



    near the end of transfer  


    but i cant believe that an 1,6 Ghz  Dual Core cpu is to weak for that 
    and 78 -80 % shouldnt slow the traffic (hope so)

    maybe any ideas ? 


    thanks a lot
  • ...but i cant believe that an 1,6 Ghz  Dual Core cpu is to weak for that


    Well, seems like 1,6GHz on an Intel Atom are not the same as 1,6GHz on a "real" CPU. ;-)

    One possible cause could be that the CPU is overloaded by interrupts coming from the different (virtual) network interfaces.

    We're currently doing performance testing in our lab, and we're trying to reproduce that with a similar scenario.
  • Well, seems like 1,6GHz on an Intel Atom are not the same as 1,6GHz on a "real" CPU. ;-)


    that for sure [[:)]]

    and thanks for your support [[:)]]

    maybe this is also useful

    Linux host.domain 2.6.32.13-14-smp64 #1 SMP Mon May 17 15:07:20 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux


    info of nic where vlans on 



    driver: e1000
    version: 7.3.21-k5-NAPI
    firmware-version: N/A
    bus-info: 0000:01:02.0      


          0x00000: CTRL (Device control register)  0x583C0241
          Endian mode (buffers):             little
          Link reset:                        normal
          Set link up:                       1
          Invert Loss-Of-Signal:             no
          Receive flow control:              enabled
          Transmit flow control:             enabled
          VLAN mode:                         enabled
          Auto speed detect:                 disabled
          Speed select:                      1000Mb/s
          Force speed:                       no
          Force duplex:                      no
    0x00008: STATUS (Device status register) 0x0000C383
          Duplex:                            full
          Link up:                           link config
          TBI mode:                          disabled
          Link speed:                        1000Mb/s
          Bus type:                          PCI
          Bus speed:                         33MHz
          Bus width:                         32-bit
    0x00100: RCTL (Receive control register) 0x00048002
          Receiver:                          enabled
          Store bad packets:                 disabled
          Unicast promiscuous:               disabled
          Multicast promiscuous:             disabled
          Long packet:                       disabled
          Descriptor minimum threshold size: 1/2
          Broadcast accept mode:             accept
          VLAN filter:                       enabled
          Canonical form indicator:          disabled
          Discard pause frames:              filtered
          Pass MAC control frames:           don't pass
          Receive buffer size:               2048
    0x02808: RDLEN (Receive desc length)     0x00001000
    0x02810: RDH   (Receive desc head)       0x00000019
    0x02818: RDT   (Receive desc tail)       0x00000017
    0x02820: RDTR  (Receive delay timer)     0x00000000
    0x00400: TCTL (Transmit ctrl register)   0x0103F0FA
          Transmitter:                       enabled
          Pad short packets:                 enabled
          Software XOFF Transmission:        disabled
          Re-transmit on late collision:     enabled
    0x03808: TDLEN (Transmit desc length)    0x00001000
    0x03810: TDH   (Transmit desc head)      0x00000097
    0x03818: TDT   (Transmit desc tail)      0x00000097
    0x03820: TIDV  (Transmit delay timer)    0x00000008
    PHY type:                                IGP


     if u need more information or data i can post, please tell me i will try to provide all is necessary to hopefully get a way to fix this
  • We've tested your scenario with our own Hardware (a small box with an Intel Celeron @600MHz), and we cannot reproduce that slowdown. With IPS disabled we reach over 600MBit/sec, even though the CPU load goes up (obviously the softinterrupts are a limiting factor). Since we do not have any Atom hardware lying around here, we're stuck.

    From the information that i have, the problem must be either related to your hardware, or your network setup. Sorry to say that, but i can't spend any more resources on this.
  • hello 

    ok i will try to setup  asg v7 with same ruleset  (a lot to do but i want it to work [[:)]] ) on the same hardware 

    i think it has something to do with the nic  maybe its really a problem with it 
    i also will try this nic in an windows machine and look how data throughput is 

    depending on the results of this tests i will also try to recompile a new driver for that intel nic  cause there is an newer version (v8.***) im not a linux guru but i hope ill be able to [[:)]]

    if no better result i also  will try to setup an other firewall on the same hardware with same rule sets and configuration (as far as possible think without smtp proxy and content management) 


    if i have any result i will post it here 

    thanks for your time and help
  • Hi, try running ifconfig and see if there are any interface errors on any of the NICs.

    Barry
  • Hi, try running ifconfig and see if there are any interface errors on any of the NICs.

    Barry


    hi i there are no errors [:(]
    i just started to setup v7 an start now the configuration 
    if all goes fine maybe i can post a result soon [[[:)]]]

    but if anyone has more ideas to switch back to v8 
    will go fast  i have the backups [[[:)]]]
    thanks [[[:)]]]
  • ok same prob with asg v7 [:(] (only did basic setup only vlans and did perf them)
    i will now try the nic in an windows pc and perf again
  • I did setup a windows machine on the same pc 
    fast transfer rate on it (800 - 860 Mb/s)so hardware is ok 

    for sure there was no ips or anything else but i only wanted to check the hardware 

    next step is i try to compile a new driver  but i have no linux machine with same kernel and sources or hardware (hope i m able on an virtual machine) so it will take a while (and maybe not all the knowledge)[;)]
  • To be honest: i do not really trust that iperf/jperf program you are using. I get really strange (read "nonsensical") results (on a direct link between two computers) with the buffer-length and window-size settings that are shown in your screenshots.

    Have you tried it with UDP?
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?