Jump to content
RESET Forums (homeservershow.com)

eero latency and timeout issues


jomobco
 Share

Recommended Posts

I'm having issues with latency and timeouts the last few days.  I'm seeing slow loading pages, etc.  It's eerily familiar with the issue I had with my WISP which now seems to be fixed with adjustments on their end (based on my pings).  I know this because I have a machine pinging them constantly on a wire connection for the last few weeks.  

 

Basically what is going on is that my ping to my main eero router will be fine (between .4ms to 10 ms or so) and then suddenly it will jump 28ms or 52ms or 128ms or 1280ms or timeout or two/three/four and then go back to normal or slowly increase in speed over a few or more pings back to normal.  

 

I contacted eero support and they asked which eero I was nearest to because and I quote:  "I am seeing some poor connections from your barn/shop2/bedroom" eero.  barn and shop2 (and shop1) are understandable.  Barn is power line adapter backhaul, shop 2 (and shop1) are 50-70' away.  Bedroom however is 12' from the main eero and has one interior wall (wood stud) and is the one I believe I'm connected to which is having problems.  eero just told me to move the bedroom eero closer to the main eero. 

 

I just started pinging the bedroom eero 10.0.0.25 and I get the same figures and the bedroom router is maybe 8' away from me.  Lows of 4ms, highs in an under 5 minute ping of 321ms and a few timeouts.  

For example:

64 bytes from 10.0.0.25: icmp_seq=505 ttl=64 time=7.194 ms

Request timeout for icmp_seq 506

64 bytes from 10.0.0.25: icmp_seq=507 ttl=64 time=18.756 ms

64 bytes from 10.0.0.25: icmp_seq=508 ttl=64 time=71.597 ms

64 bytes from 10.0.0.25: icmp_seq=509 ttl=64 time=122.088 ms

64 bytes from 10.0.0.25: icmp_seq=510 ttl=64 time=108.323 ms

64 bytes from 10.0.0.25: icmp_seq=511 ttl=64 time=204.214 ms

64 bytes from 10.0.0.25: icmp_seq=512 ttl=64 time=146.577 ms

64 bytes from 10.0.0.25: icmp_seq=513 ttl=64 time=498.028 ms

64 bytes from 10.0.0.25: icmp_seq=514 ttl=64 time=516.963 ms

64 bytes from 10.0.0.25: icmp_seq=515 ttl=64 time=146.840 ms

64 bytes from 10.0.0.25: icmp_seq=516 ttl=64 time=23.875 ms

64 bytes from 10.0.0.25: icmp_seq=517 ttl=64 time=25.369 ms

64 bytes from 10.0.0.25: icmp_seq=518 ttl=64 time=36.993 ms

64 bytes from 10.0.0.25: icmp_seq=519 ttl=64 time=17.564 ms

 

Here is one ping from the main eero:

PING 10.0.0.1 (10.0.0.1): 56 data bytes

64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=1.444 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.790 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=81.502 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=29.700 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=44.414 ms
64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=0.753 ms
64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=2.255 ms
64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=0.885 ms
64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=1.659 ms
64 bytes from 10.0.0.1: icmp_seq=9 ttl=64 time=0.833 ms
64 bytes from 10.0.0.1: icmp_seq=10 ttl=64 time=125.485 ms
64 bytes from 10.0.0.1: icmp_seq=11 ttl=64 time=33.840 ms
64 bytes from 10.0.0.1: icmp_seq=12 ttl=64 time=94.647 ms
64 bytes from 10.0.0.1: icmp_seq=13 ttl=64 time=2.841 ms
64 bytes from 10.0.0.1: icmp_seq=14 ttl=64 time=1.169 ms
64 bytes from 10.0.0.1: icmp_seq=15 ttl=64 time=0.729 ms
64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=0.870 ms
64 bytes from 10.0.0.1: icmp_seq=17 ttl=64 time=0.744 ms
64 bytes from 10.0.0.1: icmp_seq=18 ttl=64 time=113.169 ms
64 bytes from 10.0.0.1: icmp_seq=19 ttl=64 time=97.816 ms
64 bytes from 10.0.0.1: icmp_seq=20 ttl=64 time=0.647 ms
64 bytes from 10.0.0.1: icmp_seq=21 ttl=64 time=0.786 ms
64 bytes from 10.0.0.1: icmp_seq=22 ttl=64 time=0.799 ms
64 bytes from 10.0.0.1: icmp_seq=23 ttl=64 time=0.988 ms
64 bytes from 10.0.0.1: icmp_seq=24 ttl=64 time=1.000 ms
64 bytes from 10.0.0.1: icmp_seq=25 ttl=64 time=1.174 ms
64 bytes from 10.0.0.1: icmp_seq=26 ttl=64 time=20.390 ms
64 bytes from 10.0.0.1: icmp_seq=27 ttl=64 time=6.582 ms
64 bytes from 10.0.0.1: icmp_seq=28 ttl=64 time=63.165 ms
64 bytes from 10.0.0.1: icmp_seq=29 ttl=64 time=0.702 ms
64 bytes from 10.0.0.1: icmp_seq=30 ttl=64 time=0.669 ms
64 bytes from 10.0.0.1: icmp_seq=31 ttl=64 time=5.138 ms
64 bytes from 10.0.0.1: icmp_seq=32 ttl=64 time=0.802 ms
64 bytes from 10.0.0.1: icmp_seq=33 ttl=64 time=0.958 ms
64 bytes from 10.0.0.1: icmp_seq=34 ttl=64 time=37.049 ms
64 bytes from 10.0.0.1: icmp_seq=35 ttl=64 time=48.644 ms
64 bytes from 10.0.0.1: icmp_seq=36 ttl=64 time=225.833 ms
64 bytes from 10.0.0.1: icmp_seq=37 ttl=64 time=0.831 ms
64 bytes from 10.0.0.1: icmp_seq=38 ttl=64 time=0.869 ms
64 bytes from 10.0.0.1: icmp_seq=39 ttl=64 time=10.764 ms
64 bytes from 10.0.0.1: icmp_seq=40 ttl=64 time=0.589 ms
64 bytes from 10.0.0.1: icmp_seq=41 ttl=64 time=4.252 ms
64 bytes from 10.0.0.1: icmp_seq=42 ttl=64 time=1.357 ms
64 bytes from 10.0.0.1: icmp_seq=43 ttl=64 time=0.679 ms
64 bytes from 10.0.0.1: icmp_seq=44 ttl=64 time=0.682 ms
64 bytes from 10.0.0.1: icmp_seq=45 ttl=64 time=0.769 ms

 

I hope this isn't normal?  Does anyone else have a more sensible thought about what to do or what's going on or how to further troubleshoot?

Link to comment
Share on other sites

1. Are you using Eero in Router or Bridge mode?

 

 

2. Is your testing being done from a wired or a wireless client?

 

3. Have you tried testing from a different client and if so where the tests conclusive?

 

4. I would also argue that if your using Eero as the router aka the first hop that a ping time of 4 - 8ms is not good right off the bat.

 

5. is there a reason your testing using 64 bytes instead of the standard 32 bytes?

 

6. Have you tried testing using 32  bytes for say -n 20 - 30 times and if yes where the results the same?

 

Below is the results from my 32 byte ping to my single Luma in router mode, As you can see its very good and should be close to what your seeing-

 

 
C:\WINDOWS\system32>ping 192.168.55.1 -n 20
 
Pinging 192.168.55.1 with 32 bytes of data:
Reply from 192.168.55.1: bytes=32 time=2ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=2ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=2ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=2ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=2ms TTL=64
Reply from 192.168.55.1: bytes=32 time=1ms TTL=64
Reply from 192.168.55.1: bytes=32 time=3ms TTL=64
Reply from 192.168.55.1: bytes=32 time=2ms TTL=64
 
Ping statistics for 192.168.55.1:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 3ms, Average = 1ms
 
C:\WINDOWS\system32>
Edited by HSS-Dave
If you reply to a post there is no need to quote it.
Link to comment
Share on other sites

1. Are you using Eero in Router or Bridge mode?

A:  Router Mode.  

 

2. Is your testing being done from a wired or a wireless client?

Wireless client from two different machines - same location, same results.

 

3. Have you tried testing from a different client and if so where the tests conclusive?

A:  I ran two clients side by side (both wirelessly) and saw the same results.  

 

4. I would also argue that if your using Eero as the router aka the first hop that a ping time of 4 - 8ms is not good right off the bat.

A:  It's the inconsistency that's getting me.  And the packet drops.  I notice it in stalling webpages.  

 

5. is there a reason your testing using 64 bytes instead of the standard 32 bytes?

A:  it's what a Mac pings at.  

 

6. Have you tried testing using 32  bytes for say -n 20 - 30 times and if yes where the results the same?

Explain what a difference that would make - I'm sure I can buy an app to sue to accomplish this.  

 

Here is the ping to the bedroom this morning:

 

PING 10.0.0.25 (10.0.0.25): 56 data bytes

64 bytes from 10.0.0.25: icmp_seq=0 ttl=64 time=13.005 ms

64 bytes from 10.0.0.25: icmp_seq=1 ttl=64 time=10.307 ms

64 bytes from 10.0.0.25: icmp_seq=2 ttl=64 time=7.940 ms

64 bytes from 10.0.0.25: icmp_seq=3 ttl=64 time=10.407 ms

64 bytes from 10.0.0.25: icmp_seq=4 ttl=64 time=8.808 ms

64 bytes from 10.0.0.25: icmp_seq=5 ttl=64 time=8.181 ms

64 bytes from 10.0.0.25: icmp_seq=6 ttl=64 time=7.419 ms

64 bytes from 10.0.0.25: icmp_seq=7 ttl=64 time=7.593 ms

64 bytes from 10.0.0.25: icmp_seq=8 ttl=64 time=7.178 ms

64 bytes from 10.0.0.25: icmp_seq=9 ttl=64 time=9.133 ms

64 bytes from 10.0.0.25: icmp_seq=10 ttl=64 time=7.027 ms

64 bytes from 10.0.0.25: icmp_seq=11 ttl=64 time=7.608 ms

64 bytes from 10.0.0.25: icmp_seq=12 ttl=64 time=8.267 ms

64 bytes from 10.0.0.25: icmp_seq=13 ttl=64 time=5.135 ms

64 bytes from 10.0.0.25: icmp_seq=14 ttl=64 time=14.540 ms

64 bytes from 10.0.0.25: icmp_seq=15 ttl=64 time=7.252 ms

64 bytes from 10.0.0.25: icmp_seq=16 ttl=64 time=7.154 ms

64 bytes from 10.0.0.25: icmp_seq=17 ttl=64 time=8.623 ms

64 bytes from 10.0.0.25: icmp_seq=18 ttl=64 time=8.661 ms

64 bytes from 10.0.0.25: icmp_seq=19 ttl=64 time=13.272 ms

64 bytes from 10.0.0.25: icmp_seq=20 ttl=64 time=6.042 ms

64 bytes from 10.0.0.25: icmp_seq=21 ttl=64 time=5.346 ms

64 bytes from 10.0.0.25: icmp_seq=22 ttl=64 time=5.096 ms

64 bytes from 10.0.0.25: icmp_seq=23 ttl=64 time=8.330 ms

64 bytes from 10.0.0.25: icmp_seq=24 ttl=64 time=7.255 ms

64 bytes from 10.0.0.25: icmp_seq=25 ttl=64 time=7.244 ms

64 bytes from 10.0.0.25: icmp_seq=26 ttl=64 time=7.296 ms

64 bytes from 10.0.0.25: icmp_seq=27 ttl=64 time=4.759 ms

64 bytes from 10.0.0.25: icmp_seq=28 ttl=64 time=4.412 ms

64 bytes from 10.0.0.25: icmp_seq=29 ttl=64 time=7.146 ms

64 bytes from 10.0.0.25: icmp_seq=30 ttl=64 time=7.225 ms

64 bytes from 10.0.0.25: icmp_seq=31 ttl=64 time=9.343 ms

64 bytes from 10.0.0.25: icmp_seq=32 ttl=64 time=7.397 ms

64 bytes from 10.0.0.25: icmp_seq=33 ttl=64 time=102.976 ms

64 bytes from 10.0.0.25: icmp_seq=34 ttl=64 time=19.322 ms

64 bytes from 10.0.0.25: icmp_seq=35 ttl=64 time=350.792 ms

64 bytes from 10.0.0.25: icmp_seq=36 ttl=64 time=126.846 ms

64 bytes from 10.0.0.25: icmp_seq=37 ttl=64 time=101.766 ms

64 bytes from 10.0.0.25: icmp_seq=38 ttl=64 time=62.016 ms

64 bytes from 10.0.0.25: icmp_seq=39 ttl=64 time=16.335 ms

64 bytes from 10.0.0.25: icmp_seq=40 ttl=64 time=7.265 ms

64 bytes from 10.0.0.25: icmp_seq=41 ttl=64 time=7.128 ms

64 bytes from 10.0.0.25: icmp_seq=42 ttl=64 time=8.228 ms

64 bytes from 10.0.0.25: icmp_seq=43 ttl=64 time=101.438 ms

64 bytes from 10.0.0.25: icmp_seq=44 ttl=64 time=20.561 ms

64 bytes from 10.0.0.25: icmp_seq=45 ttl=64 time=7.156 ms

64 bytes from 10.0.0.25: icmp_seq=46 ttl=64 time=6.187 ms

64 bytes from 10.0.0.25: icmp_seq=47 ttl=64 time=7.197 ms

64 bytes from 10.0.0.25: icmp_seq=48 ttl=64 time=19.583 ms

64 bytes from 10.0.0.25: icmp_seq=49 ttl=64 time=4.692 ms

64 bytes from 10.0.0.25: icmp_seq=50 ttl=64 time=132.382 ms

64 bytes from 10.0.0.25: icmp_seq=51 ttl=64 time=7.401 ms

64 bytes from 10.0.0.25: icmp_seq=52 ttl=64 time=16.764 ms

64 bytes from 10.0.0.25: icmp_seq=53 ttl=64 time=56.840 ms

64 bytes from 10.0.0.25: icmp_seq=54 ttl=64 time=94.035 ms

64 bytes from 10.0.0.25: icmp_seq=55 ttl=64 time=90.151 ms

64 bytes from 10.0.0.25: icmp_seq=56 ttl=64 time=28.266 ms

64 bytes from 10.0.0.25: icmp_seq=57 ttl=64 time=528.844 ms

Request timeout for icmp_seq 58

64 bytes from 10.0.0.25: icmp_seq=58 ttl=64 time=1007.747 ms

64 bytes from 10.0.0.25: icmp_seq=59 ttl=64 time=77.331 ms

64 bytes from 10.0.0.25: icmp_seq=60 ttl=64 time=29.994 ms

64 bytes from 10.0.0.25: icmp_seq=61 ttl=64 time=51.272 ms

64 bytes from 10.0.0.25: icmp_seq=62 ttl=64 time=115.952 ms

64 bytes from 10.0.0.25: icmp_seq=63 ttl=64 time=15.295 ms

64 bytes from 10.0.0.25: icmp_seq=64 ttl=64 time=81.520 ms

64 bytes from 10.0.0.25: icmp_seq=65 ttl=64 time=26.616 ms

64 bytes from 10.0.0.25: icmp_seq=66 ttl=64 time=1007.086 ms

64 bytes from 10.0.0.25: icmp_seq=67 ttl=64 time=63.992 ms

64 bytes from 10.0.0.25: icmp_seq=68 ttl=64 time=21.950 ms

64 bytes from 10.0.0.25: icmp_seq=69 ttl=64 time=29.055 ms

64 bytes from 10.0.0.25: icmp_seq=70 ttl=64 time=83.693 ms

64 bytes from 10.0.0.25: icmp_seq=71 ttl=64 time=161.698 ms

64 bytes from 10.0.0.25: icmp_seq=72 ttl=64 time=159.406 ms

64 bytes from 10.0.0.25: icmp_seq=73 ttl=64 time=48.322 ms

64 bytes from 10.0.0.25: icmp_seq=74 ttl=64 time=1007.918 ms

64 bytes from 10.0.0.25: icmp_seq=74 ttl=64 time=1007.934 ms (DUP!)

64 bytes from 10.0.0.25: icmp_seq=75 ttl=64 time=200.224 ms

64 bytes from 10.0.0.25: icmp_seq=76 ttl=64 time=59.858 ms

64 bytes from 10.0.0.25: icmp_seq=77 ttl=64 time=20.153 ms

64 bytes from 10.0.0.25: icmp_seq=78 ttl=64 time=81.325 ms

64 bytes from 10.0.0.25: icmp_seq=79 ttl=64 time=113.209 ms

64 bytes from 10.0.0.25: icmp_seq=80 ttl=64 time=138.018 ms

64 bytes from 10.0.0.25: icmp_seq=81 ttl=64 time=124.640 ms

64 bytes from 10.0.0.25: icmp_seq=82 ttl=64 time=41.993 ms

64 bytes from 10.0.0.25: icmp_seq=83 ttl=64 time=40.271 ms

64 bytes from 10.0.0.25: icmp_seq=84 ttl=64 time=81.803 ms

64 bytes from 10.0.0.25: icmp_seq=85 ttl=64 time=85.891 ms

64 bytes from 10.0.0.25: icmp_seq=86 ttl=64 time=21.081 ms

64 bytes from 10.0.0.25: icmp_seq=87 ttl=64 time=45.505 ms

64 bytes from 10.0.0.25: icmp_seq=88 ttl=64 time=63.261 ms

64 bytes from 10.0.0.25: icmp_seq=89 ttl=64 time=24.096 ms

64 bytes from 10.0.0.25: icmp_seq=90 ttl=64 time=22.985 ms

64 bytes from 10.0.0.25: icmp_seq=91 ttl=64 time=63.878 ms

64 bytes from 10.0.0.25: icmp_seq=92 ttl=64 time=25.593 ms

64 bytes from 10.0.0.25: icmp_seq=93 ttl=64 time=259.902 ms

64 bytes from 10.0.0.25: icmp_seq=94 ttl=64 time=37.941 ms

64 bytes from 10.0.0.25: icmp_seq=95 ttl=64 time=150.293 ms

64 bytes from 10.0.0.25: icmp_seq=96 ttl=64 time=110.980 ms

64 bytes from 10.0.0.25: icmp_seq=97 ttl=64 time=26.514 ms

64 bytes from 10.0.0.25: icmp_seq=98 ttl=64 time=26.996 ms

Link to comment
Share on other sites

Instead of letting it "self heal" I decided to reboot the main eero and the bedroom eero.  Here are the results so far.  Promising.  I'm guessing that the bedroom eero decided to connect to a weaker shop eero instead of to the main eero just 12' away or so.  The reboot might have solved this.  

PING 10.0.0.25 (10.0.0.25): 56 data bytes

64 bytes from 10.0.0.25: icmp_seq=0 ttl=64 time=1.980 ms

64 bytes from 10.0.0.25: icmp_seq=1 ttl=64 time=0.924 ms

64 bytes from 10.0.0.25: icmp_seq=2 ttl=64 time=3.477 ms

64 bytes from 10.0.0.25: icmp_seq=3 ttl=64 time=0.938 ms

64 bytes from 10.0.0.25: icmp_seq=4 ttl=64 time=1.300 ms

64 bytes from 10.0.0.25: icmp_seq=5 ttl=64 time=20.519 ms

64 bytes from 10.0.0.25: icmp_seq=6 ttl=64 time=3.472 ms

64 bytes from 10.0.0.25: icmp_seq=7 ttl=64 time=2.570 ms

64 bytes from 10.0.0.25: icmp_seq=8 ttl=64 time=3.653 ms

64 bytes from 10.0.0.25: icmp_seq=9 ttl=64 time=3.554 ms

64 bytes from 10.0.0.25: icmp_seq=10 ttl=64 time=3.310 ms

64 bytes from 10.0.0.25: icmp_seq=11 ttl=64 time=1.049 ms

64 bytes from 10.0.0.25: icmp_seq=12 ttl=64 time=3.705 ms

64 bytes from 10.0.0.25: icmp_seq=13 ttl=64 time=1.130 ms

64 bytes from 10.0.0.25: icmp_seq=14 ttl=64 time=3.977 ms

64 bytes from 10.0.0.25: icmp_seq=15 ttl=64 time=3.433 ms

64 bytes from 10.0.0.25: icmp_seq=16 ttl=64 time=2.953 ms

64 bytes from 10.0.0.25: icmp_seq=17 ttl=64 time=1.419 ms

64 bytes from 10.0.0.25: icmp_seq=18 ttl=64 time=1.001 ms

64 bytes from 10.0.0.25: icmp_seq=19 ttl=64 time=1.005 ms

64 bytes from 10.0.0.25: icmp_seq=20 ttl=64 time=0.859 ms

64 bytes from 10.0.0.25: icmp_seq=21 ttl=64 time=1.083 ms

64 bytes from 10.0.0.25: icmp_seq=22 ttl=64 time=0.957 ms

64 bytes from 10.0.0.25: icmp_seq=23 ttl=64 time=0.877 ms

64 bytes from 10.0.0.25: icmp_seq=24 ttl=64 time=0.810 ms

64 bytes from 10.0.0.25: icmp_seq=25 ttl=64 time=3.411 ms

64 bytes from 10.0.0.25: icmp_seq=26 ttl=64 time=0.913 ms

64 bytes from 10.0.0.25: icmp_seq=27 ttl=64 time=0.924 ms

64 bytes from 10.0.0.25: icmp_seq=28 ttl=64 time=3.538 ms

64 bytes from 10.0.0.25: icmp_seq=29 ttl=64 time=3.359 ms

64 bytes from 10.0.0.25: icmp_seq=30 ttl=64 time=0.948 ms

64 bytes from 10.0.0.25: icmp_seq=31 ttl=64 time=1.499 ms

64 bytes from 10.0.0.25: icmp_seq=32 ttl=64 time=0.684 ms

64 bytes from 10.0.0.25: icmp_seq=33 ttl=64 time=0.946 ms

6

Link to comment
Share on other sites

I'm now getting 5-10ms pings to my main eero.  Not sure about this self healing thing and online management.  Couldn't support figure this out knowing how close the bedroom eero was to the main eero?  

Link to comment
Share on other sites

Instead of letting it "self heal" I decided to reboot the main eero and the bedroom eero.  Here are the results so far.  Promising.  I'm guessing that the bedroom eero decided to connect to a weaker shop eero instead of to the main eero just 12' away or so.  The reboot might have solved this.  

PING 10.0.0.25 (10.0.0.25): 56 data bytes

64 bytes from 10.0.0.25: icmp_seq=0 ttl=64 time=1.980 ms

64 bytes from 10.0.0.25: icmp_seq=1 ttl=64 time=0.924 ms

64 bytes from 10.0.0.25: icmp_seq=2 ttl=64 time=3.477 ms

64 bytes from 10.0.0.25: icmp_seq=3 ttl=64 time=0.938 ms

64 bytes from 10.0.0.25: icmp_seq=4 ttl=64 time=1.300 ms

64 bytes from 10.0.0.25: icmp_seq=5 ttl=64 time=20.519 ms

64 bytes from 10.0.0.25: icmp_seq=6 ttl=64 time=3.472 ms

64 bytes from 10.0.0.25: icmp_seq=7 ttl=64 time=2.570 ms

64 bytes from 10.0.0.25: icmp_seq=8 ttl=64 time=3.653 ms

64 bytes from 10.0.0.25: icmp_seq=9 ttl=64 time=3.554 ms

64 bytes from 10.0.0.25: icmp_seq=10 ttl=64 time=3.310 ms

64 bytes from 10.0.0.25: icmp_seq=11 ttl=64 time=1.049 ms

64 bytes from 10.0.0.25: icmp_seq=12 ttl=64 time=3.705 ms

64 bytes from 10.0.0.25: icmp_seq=13 ttl=64 time=1.130 ms

64 bytes from 10.0.0.25: icmp_seq=14 ttl=64 time=3.977 ms

64 bytes from 10.0.0.25: icmp_seq=15 ttl=64 time=3.433 ms

64 bytes from 10.0.0.25: icmp_seq=16 ttl=64 time=2.953 ms

64 bytes from 10.0.0.25: icmp_seq=17 ttl=64 time=1.419 ms

64 bytes from 10.0.0.25: icmp_seq=18 ttl=64 time=1.001 ms

64 bytes from 10.0.0.25: icmp_seq=19 ttl=64 time=1.005 ms

64 bytes from 10.0.0.25: icmp_seq=20 ttl=64 time=0.859 ms

64 bytes from 10.0.0.25: icmp_seq=21 ttl=64 time=1.083 ms

64 bytes from 10.0.0.25: icmp_seq=22 ttl=64 time=0.957 ms

64 bytes from 10.0.0.25: icmp_seq=23 ttl=64 time=0.877 ms

64 bytes from 10.0.0.25: icmp_seq=24 ttl=64 time=0.810 ms

64 bytes from 10.0.0.25: icmp_seq=25 ttl=64 time=3.411 ms

64 bytes from 10.0.0.25: icmp_seq=26 ttl=64 time=0.913 ms

64 bytes from 10.0.0.25: icmp_seq=27 ttl=64 time=0.924 ms

64 bytes from 10.0.0.25: icmp_seq=28 ttl=64 time=3.538 ms

64 bytes from 10.0.0.25: icmp_seq=29 ttl=64 time=3.359 ms

64 bytes from 10.0.0.25: icmp_seq=30 ttl=64 time=0.948 ms

64 bytes from 10.0.0.25: icmp_seq=31 ttl=64 time=1.499 ms

64 bytes from 10.0.0.25: icmp_seq=32 ttl=64 time=0.684 ms

64 bytes from 10.0.0.25: icmp_seq=33 ttl=64 time=0.946 ms

6

It sounds like you are using wireless mesh? If so using Ethernet backhaul would be better.

I'm now getting 5-10ms pings to my main eero.  Not sure about this self healing thing and online management.  Couldn't support figure this out knowing how close the bedroom eero was to the main eero?  

That's still a bit high for the first hop. Should be no more then <0 - 2ms

Link to comment
Share on other sites

If I had ethernet backhaul as an option I might not have purchased a wireless mesh system :)  5-10ms was (and I'm guessing because I can't see it) from the laptop through the bedroom eero to the main eero.  The bedroom eero is now pinging at the same rate as your Luma give or take.  

Link to comment
Share on other sites

If I had ethernet backhaul as an option I might not have purchased a wireless mesh system :)  5-10ms was (and I'm guessing because I can't see it) from the laptop through the bedroom eero to the main eero.  The bedroom eero is now pinging at the same rate as your Luma give or take.  

There are many advantages to using a mesh system, wireless mesh is only part it as there is also the wired mesh. I am sorry but I thought you where using powerline in the barn to provided Ethernet backhaul? So I asked about the other Eero's. If you use powerline to the other Eero's you may see better results but testing would be needed. I say 5-10ms is way to high for the first hop regardless, I am getting those pings to the outside world doing a tracert to google across 10 hops from my wireless laptop have a look below-

 

 
C:\WINDOWS\system32>tracert google.com
 
Tracing route to google.com [172.217.0.46]
over a maximum of 30 hops:
 
  1     1 ms     3 ms     1 ms  luma.lan [192.168.55.1]
  2     6 ms     2 ms     2 ms  192.168.1.1
  3     4 ms     2 ms     2 ms  lo0-100.NWRKNJ-VFTTP-301.verizon-gni.net [123.123.123.456]
  4     8 ms     6 ms     7 ms  B3301.NWRKNJ-LCR-21.verizon-gni.net [123.123.123.456]
  5     *        *        *     Request timed out.
  6     8 ms     7 ms     6 ms  0.ae11.GW13.NYC1.ALTER.NET [140.222.234.191]
  7     5 ms     6 ms     8 ms  google-gw.customer.alter.net [204.148.18.34]
  8     5 ms     6 ms     6 ms  216.239.50.141
  9     8 ms     8 ms     9 ms  209.85.245.179
 10     8 ms     8 ms    11 ms  lga15s43-in-f46.1e100.net [172.217.0.46]
 
Trace complete.
 
C:\WINDOWS\system32>
Link to comment
Share on other sites

 

There are many advantages to using a mesh system, wireless mesh is only part it as there is also the wired mesh. I am sorry but I thought you where using powerline in the barn to provided Ethernet backhaul? So I asked about the other Eero's. If you use powerline to the other Eero's you may see better results but testing would be needed. I say 5-10ms is way to high for the first hop regardless, I am getting those pings to the outside world doing a tracert to google across 10 hops from my wireless laptop have a look below-

 

 
C:\WINDOWS\system32>

 

 

There is a powerline backhaul to the barn however the barn is 75' away from the house and 60' away from the shop so no wireless mesh to speak of.  I've watched my ethernet over powerline speeds.  The barn is 10-30 mbps.  Bedroom was 110 or so and the living room was 60 or so.  All would fluctuate by 50%.  With the bedroom to main eero being 12' away the wireless backhaul should be faster.  2 hops I'm getting what you get with 30 hops.  What I was really disappointed with was the fact that when I contacted support, and they told me that the bedroom had a poor signal to the main eero, and I told them it was 15' away.  They just said to move it closer.  What kind of solution is that?  If I were them I would think I would want to look at why this is happening since to me this seems to be a problem.  Just reboot is not a solution in my book.  I guess I expect too much from companies when I buy premium products.  I think I may go back to my Apple set-up and look into hard wiring.  

  • Like 1
Link to comment
Share on other sites

OK so eero has been fantastic about getting me an RA with no restocking for all of my units.  I expected no less from eero as overall my experience with them has been very good - with this one exception.  My pings from one machine are still the same as of a few moments ago.  The eero I think I'm connected to is similar in ping ms as it was before (zero.something to 4.something) and the main eero with one hop is still 3.somthing to 9.something.  Granted I'm not getting out two laptops again to measure ping speed side by side as I did before because my results were virtually the same when I did.  As some have mentioned in other threads it could be a machine issue however It's not the slow pings that are bothering me but the packet drops.  They are effecting page loading, etc I believe and it's an issue for me.  I haven't seen this issue again for a few days now.  Everything has been steady as of late.  

 

Here's my rub in depth - these things were a lot of money.  I have high expectations when I buy a premium product.  I won't apologize for having the same expectations of performance on a high end product regardless of what industry it may be in.  I don't care if it's a car, a mobile or computing device, restaurants or routers.  Don't promise if you can't deliver.  I have little forgiveness for a company wanting to be first to market even though I fully understand why they want to do it a business perspective.  That's one the reasons why I never opened my Luma.  It was a sh&t show from the ship date and that speaks volumes to me.  And then compound the lies and broken promises they dished out into the equation and their BS line exceeded my expected happiness line.  

 

This is not the only issue I've had with eero.  I've opened 3 support tickets so far.  One was caused by my WISP and eero was courteous enough to humor me and look into it.  I don't know if they took that as a strike against me and if that may have played into the current situation or not.  Maybe it lead into a more lackadaisical attitude by my customer service person when they read the notes that my first ticket turned out to not to be eero related.  I don't know.  My second ticket a few weeks ago was due to a connection issue I believe was happening off of my living room eero.  This issue occurred after the unit had been up and running solidly for weeks.  Suddenly I had three devices, all Apple, which would struggle and fail to connect.  One was an iPhone and two were Macbooks.  They would connect, get assigned an IP, and then drop.  Reconnect, get assigned and IP and then get dropped.  Repeatedly.  Endlessly.  I opened a ticket so that eero could look at the device, which they said they did.  They wanted me to swap the device out (I have a few extra).  Instead I rebooted it and haven't had that problem again.  The third issue I've had is with random dropping of a client off of the eero network.  I will notice my Apple laptops on occasion (days to weeks or more apart) suddenly be trying to reconnect.  On occasion I've had to physically click on the network from the drop down menu for it to reconnect.  I've seen this multiple times on multiple laptops.  I've ignored this as eventually they reconnect.  The problem doesn't last long enough to get a ticket started and then it's a few day or weeks until it occurs again.

 

I've been in beta on numerous Apple software launches dating back a few years.  I love Apple software and at the time I was happy to help where I could. As I've gotten busier in life and the novelty has worn off I've stopped doing it.  For me life has become too short.  I've got so much to do and not enough time to do it in.  I do love the way eero runs it's company.  Strong communication, promise and deliver, not perfect but great effort always seems to be shown to always be moving forward and improving.  They are customer centric.  They kept people in the loop when they were trying to launch.  All of their early supporters knew the situation and were kept abreast of the many issues as they arose at least from what I've read.  To me this speaks volumes about a company's integrity.  Much like Apple I like eero's toy box and for the most part I like to play in it.  I don't mind that I can't play with certain toys because overall it makes my life better and easier.  

 

I'm no tech expert.  It's not my field.  There are a lot of products coming to market in this consumer mesh arena.  eero has been kind enough to hand me RA's for the product and basically let me test them for 30 days or so.  Kudos to them.  Are the problems that I speak of fixable?  What is everyone's best take on them getting it fixed?  And as The Clash might say, "Should I stay or should I go now?"  If I stay I certainly need to reach out verbally to eero and express my displeasure with the situation.  I also need thank them for being so generous with giving me exit options.  I think either way I'm on the path of wiring my property.  I'm in communication with a company to wire my buildings together.  With my buildings and my house being hardwired it will certainly solve a lot of problems and create much more harmony with my network.  

 

Comments and thoughts please...

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...