ping rtt on fw4b



  • hi all,
    i tried pfsense, linux vm on windows server with hyper-v and on kvm.
    in all cases ping rtt was 1-2 seconds more when pinging lan gateway from vm, compared to ping from host os.
    why such lag? is it bad hardware?
    i noticed fw4b comes with intel i210, most other models have 82583v cards

    https://groups.google.com/d/msg/fa.linux.kernel/fohLv7aaHMs/PcMG4r_PBwAJ


  • Netgate Administrator

    That's catastrophically bad latency. Something must have been pretty seriously broken to do that. Or deliberately configured to introduce that delay.
    You actually mean seconds not milliseconds?

    Steve



  • yes seconds, this is what i pretty much did, except i used different virtualization platform and pfsense then linux as guest OSes:

    cannot post link some error about spam

    look at photo when he pings virtual machine:

    ping 192.168.1.1

    His RTT stays under 1 seconds, in my case I have RTT between 1-2 seconds.
    Must be network card I210-AT to blame huh?


  • Netgate Administrator

    There is almost nothing that can add 2 seconds RTT to a local host. You could do that in pfSense using Limiters to simulate a very high latency link. That would have to be deliberately configured though.
    You must have buffering somewhere that is badly broken/misconfigured.

    Steve



  • I am so sorry, so embarrassed, let me correct - this is what I see when pinging LAN gateway:

    From host machine:

    ping 192.168.1.1
    PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
    64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.708 ms
    64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.686 ms
    64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.682 ms

    From virtual  machine:

    ping 192.168.1.1
    PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
    64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.75 ms
    64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.82 ms
    64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.05 ms

    this is probably ok yes?
    it still bothers me though because on PC I do not see such problem.


  • LAYER 8 Global Moderator

    So your seeing like a 1ms delay going through how much virtual hardware.. So you have a VM, talking to another VM, then routes it and then nats it, and then in software it bridges it from its virtual wan nic to the physical nic then out to your gateway.. And your concerned with a 1ms added latency?

    This is NOT an issue.. And yes would be expected..



  • yes, thank you for all replies!
    as said it bothered me because on desktop PC (with single NIC) i did not see such delay.
    I imagined with more traffic this could affect performance.


  • LAYER 8 Global Moderator

    So how much delay do you think would be expected with all the stuff your doing in your VM setup?

    Well yeah with your pc your not doing all that stuff in software on your vm host machine.. 0.001 of second added latency round trip is not be noticeable...

    Not unless your wanting to do some serious high speed stock trading ;)



  • well FW4B has 4 cores, 4 NICs, with single virtual machine running only pings I would expect no delay


  • LAYER 8 Global Moderator

    @netgpf said in ping rtt on fw4b:

    I would expect no delay

    Well then you don't understand how stuff works ;) It could be a gawd damn cray super computer, and there is still going to be delay.. Because your adding process!!!

    If you don't want the couple of ms of added delay your seeing while doing stuff in VM, then do it all in hardware!

    Again think about what is going on here... And your seeing 0.001 extra in your ping.



  • again sorry and thanks again

    p.s. however it is not "couple of ms of added delay", delay almost doubled


  • LAYER 8 Global Moderator

    Do you really think 0.001 is going to be noticeable when your talking to something say .030 seconds away? Really??


  • Netgate Administrator

    Yeah 2ms through a VM is expected. No fault found. 😉


  • LAYER 8 Global Moderator

    Is not just 1 VM - he has 2, he has a VM talking to another VM on the same host, where this other vm (pfsense) is then routing and natting the traffic (going to be a delay there even in hardware) and then having to software bridge that to the physical nic though through the VM software..

    No freaking shit there is going to be a bit of added delay ;)



  • @johnpoz
    no no, it was single vm runing on hyper-v pinging physical router


  • LAYER 8 Global Moderator

    Well maybe hyperV is just crap then ;) I only see around 0.2 ms delay from vms running on my nas, vs the nas itself pinging the physical pfsense.

    Some delay is to be expected... unless you were talking 10s of ms I wouldn't be concerned that something is not right.

    Are you natting in hyper-v or bridge?



  • These ping results were with bridge.
    After your question I switched to natted adapter and surely no delay between two VMs within natted virtual network but then again I would need bridge as said to be able access physical appliances, I mean without modifications to existing LAN.
    My problem description is somewhat similar to this one:
    https://forum.netgate.com/topic/148937/gateway-increased-ping-latency-depending-on-the-esxi-version-from-the-web-interface-not-from-ssh

    Presumably he solved issue with different drivers, but he had like 6ms pings not 2ms.
    Should I go to virtualization forum?

    P.S. just to clarify:
    with natted adapter there is no delay within natted virtual network but there is same delay when pinging LAN gateway.


  • Netgate Administrator

    Yeah 2ms is not something that would concern me but it is a virtualisation issue so better to open a thread there to investigate it.

    Steve


  • LAYER 8 Global Moderator

    When you say natted no delay you mean between vms behind the same natted connection? Or from natted connection to your gateway.. You can still function with a natted network to your physical network. Other than port forwarding from your physical to your natted devices would be required for unsolicited traffic from your physical to your natted vms..

    If you feel your VM solution is adding unwarranted extra delay - then yeah you would need to get with your VM software solution support... This has zero to do with pfsense..


Log in to reply