ping rtt on fw4b
-
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 msFrom 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 msthis is probably ok yes?
it still bothers me though because on PC I do not see such problem. -
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. -
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
-
@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
-
Do you really think 0.001 is going to be noticeable when your talking to something say .030 seconds away? Really??
-
Yeah 2ms through a VM is expected. No fault found.
-
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 -
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-sshPresumably 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. -
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
-
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..
