Menu
Reply
  • 207
  • 2
  • 44
wotusaw
Superfast
803 Views
Message 2941 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause

cje85@

"Are you using WiFi or wired? This is what I get with 9.1.116BA3"

 

Nope, using wired and the very bestest cable money can buy from pc to hub3.

 

Yes, Boltedenergy....should have kept my mouth shut!!Smiley Frustrated

 

I had an engineer here saturday and he picked it up and shove his tester on it/whatever. But don't think he could have messed it up. Maybe it's the rain?

I just don't know. This is the worst it's been. It was not like this after the new patch awhiles back.

0 Kudos
Reply
  • 227
  • 6
  • 15
StormW4tch3r
Up to speed
792 Views
Message 2942 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause

New firmware is being pushed out by postcode (according to live chat person).

0 Kudos
Reply
  • 199
  • 5
  • 24
ColinTaylor
Superfast
758 Views
Message 2943 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause

OK Just another FYI.

I've been testing the new firmware since I got it this morning and these are my observations.

1. As reported elsewhere the BQM latency graph now looks "normal" and ICMP pings don't suffer the previous spikes.

2. The Puma 6 test shows all green, again without the intermittent red blocks.

3. Intermittent (about every 20 seconds or so) TCP latency spikes are still there for requests of more than a few hundred bytes. Smaller requests like those used in the Puma 6 test do not suffer from this.

4. Overall "feel" with general browsing is noticeably improved. I can't comment about online gaming as I don't do that.

So in summary, the new firmware does a good job at masking the worst effects of the Puma 6 problem but the underlying problem is still present.

0 Kudos
Reply
  • 63
  • 0
  • 13
yabba
Dialled in
728 Views
Message 2944 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause


@wrote:

I'm not talking about whole screen tearing.  This effect is within polygons that have a texture being displayed.  No amount of hardware synch fixes can alter the fact that the client has to catch up by the example of 8-9 frames, and that the client will be mapping a different image to that displayed before. The jerky movement of some other players is an obvious effect, if you consider what has to happen when a texture across an area of screen has the same jump, what you'll have is a momentary thin wedge of missing or overlapping image.  It's like cutting a sheet of graph paper and putting it back at a very slight angle - either side the pattern is the same, but it won't join correctly, creating that obvious discontinuity, that in a game appears as a tear

 

Yeah, but no. https://developer.valvesoftware.com/wiki/Lag_compensation This might help you understand what happens. Texture mapped polygons are textured mapped. The mapping doesn't move because a packet is delayed or lost.
0 Kudos
Reply
Highlighted
  • 704
  • 90
  • 304
Andruser
Rising star
686 Views
Message 2945 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause

It isn't a single lost packet, it's eight-twelve entire frames that we're talking about.  I'd agree that a few lost packets are neither here nor there, but when you're have a PC trying top catch up on ten complete screen refreshes, that's rather a lot of data in a fast moving game.  There's still only the two options I've indicated - the PC has to make up and blend two different images, or there's going to be discontinuity on the screen.

0 Kudos
Reply
  • 209
  • 2
  • 73
boltedenergy
Superfast
655 Views
Message 2946 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause

LAN TO WAN SIDE:

PING www.google.co.uk (216.58.204.3) 56(84) bytes of data.
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=1 ttl=54 time=15.8 ms
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=2 ttl=54 time=14.6 ms
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=3 ttl=54 time=11.7 ms
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=4 ttl=54 time=12.1 ms
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=5 ttl=54 time=12.9 ms
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=6 ttl=54 time=21.9 ms
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=7 ttl=54 time=12.9 ms
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=8 ttl=54 time=14.0 ms
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=9 ttl=54 time=12.6 ms
64 bytes from lhr35s07-in-f3.1e100.net (216.58.204.3): icmp_seq=10 ttl=54 time=12.2 ms

LAN TO LAN SIDE:

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=2.42 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=1.46 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1.92 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=2.01 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=1.96 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=1.97 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=2.01 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=1.99 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=1.94 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=2.00 ms

0 Kudos
Reply
  • 96
  • 0
  • 9
Badvok
Dialled in
647 Views
Message 2947 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause


wrote:

It isn't a single lost packet, it's eight-twelve entire frames that we're talking about.  I'd agree that a few lost packets are neither here nor there, but when you're have a PC trying top catch up on ten complete screen refreshes, that's rather a lot of data in a fast moving game.  There's still only the two options I've indicated - the PC has to make up and blend two different images, or there's going to be discontinuity on the screen.


Are you talking about game streaming rather than running locally? If so I guess what you are saying makes sense but there are so many other potential issues that I doubt you could isolate it to the Puma 6 issue.

0 Kudos
Reply
  • 138
  • 1
  • 53
falconevo
Superfast
602 Views
Message 2948 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause

Is this utilising Wifi as I wouldn't expect more than <1ms to 1ms from a wired connection unless you are using HomePlug devices.

Not sure why it wouldn't let me quote you on my reply @boltedenergy

0 Kudos
Reply
  • 14
  • 0
  • 0
Phyix123
Tuning in
570 Views
Message 2949 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause

Tried a few games and most of my issue's seem to have reduced. 

5ee1e56e482fc3c692d3c966a942e31624b40aa3  
0 Kudos
Reply
  • 209
  • 2
  • 73
boltedenergy
Superfast
553 Views
Message 2950 of 3,946
Flag for a moderator

Re: Hub 3 / Compal CH7465-LG (TG2492LG) and CGNV4 Latency Cause


@wrote:

Is this utilising Wifi as I wouldn't expect more than <1ms to 1ms from a wired connection unless you are using HomePlug devices.

Not sure why it wouldn't let me quote you on my reply @boltedenergy



It's wired Ethernet 1Gbps connection from my desktop workstation to the SH3 router (directly connected).

The reason for the variance (although much improved in this firmware) is due to the SH3's dodgy puma6 chipset issues.

I ran the same from a desktop (linux) to a desktop (windows 10) inside my LAN as below:

PING 192.168.0.45 (192.168.0.45) 56(84) bytes of data.
64 bytes from 192.168.0.45: icmp_seq=1 ttl=128 time=0.508 ms
64 bytes from 192.168.0.45: icmp_seq=2 ttl=128 time=0.839 ms
64 bytes from 192.168.0.45: icmp_seq=3 ttl=128 time=0.485 ms
64 bytes from 192.168.0.45: icmp_seq=4 ttl=128 time=0.490 ms
64 bytes from 192.168.0.45: icmp_seq=5 ttl=128 time=0.479 ms
64 bytes from 192.168.0.45: icmp_seq=6 ttl=128 time=0.486 ms
64 bytes from 192.168.0.45: icmp_seq=7 ttl=128 time=0.494 ms
64 bytes from 192.168.0.45: icmp_seq=8 ttl=128 time=0.869 ms
64 bytes from 192.168.0.45: icmp_seq=9 ttl=128 time=0.882 ms
64 bytes from 192.168.0.45: icmp_seq=10 ttl=128 time=1.24 ms


0 Kudos
Reply