Fun with SEQ Log :-)

Bryan W4WMT
Posts: 80
Joined: Sun Apr 09, 2017 10:12 pm

Fun with SEQ Log :-)

Postby Bryan W4WMT » Fri Nov 08, 2019 1:44 pm

Hi All,

One of the more interesting results from playing with Richie's new SEQ Log is the phenomenon of repeated packets! Consider a snapshot like this, eg from one of the DDCs:

0 0 0 0 0 -2 0 0 0 0...

AFAIK, the only way to produce a snapshot with deltas like that is for a packet to be repeated.
The mind boggles :roll:

73
User avatar
w-u-2-o
Posts: 1895
Joined: Fri Mar 10, 2017 1:47 pm

Re: Fun with SEQ Log :-)

Postby w-u-2-o » Fri Nov 08, 2019 3:35 pm

I've yet to see a negative number in my seq log. Only positives, sometimes large ones. If I ever hear any audio glitches, which typically only happen when I ask the PC to do something else like load a complex web page, I am sure to see some entries in the seq log showing packet drop outs (positive numbers). I have no idea if this is NIC, IP stack, or blocked thread related. I am most suspicious of blocked threads, though, as since I adjusted things to eliminate the dreaded red box indicator of blocked display threads I almost never get drop outs under any circumstances.
Bryan W4WMT
Posts: 80
Joined: Sun Apr 09, 2017 10:12 pm

Re: Fun with SEQ Log :-)

Postby Bryan W4WMT » Fri Nov 08, 2019 4:18 pm

I agree that a "lone wolf" cluster of dropped packets (indicated by a single positive delta) is probably due to a blocked thread during a very busy period where the computer is off doing other things unrelated to its SDR duties. The DDC, DUC, and audio streaming threads in Thetis are already being given the highest possible priority available to any Windows task (other than kernel stuff) thanks to the MMCSS, but there's only so much the thread scheduler can do before it gives up and dumps data on the floor.

Repeated packets, though, are a mystery to me. Wouldn't that almost have to be a bug in the fpga? Can the Windows stack do something like that on its own?

73
User avatar
w-u-2-o
Posts: 1895
Joined: Fri Mar 10, 2017 1:47 pm

Re: Fun with SEQ Log :-)

Postby w-u-2-o » Fri Nov 08, 2019 5:04 pm

Yes, in fact that was why Warren put the packet reordering code into PowerSDR. In fact, we were all waiting for the first instance of negative numbers to be reported, so congratulations ;)

@ramdor: negative numbers in Bryan's seq log...
User avatar
ramdor
Posts: 281
Joined: Wed Jul 03, 2019 3:07 pm

Re: Fun with SEQ Log :-)

Postby ramdor » Fri Nov 08, 2019 5:59 pm

I would have expected some more non 0 numbers in the next snapshot really. If there are no more seq errors above -2 line, then the packet following the sequence number from the -2 picket is now correctly sequenced. In essence everything went back 2 sequence numbers.

I would have expected something like this...

DCC2
s0=0 0 0 0 0 0 0 0 0 0 0 0 0 -2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11/08 17:39:24:124
s1=0 0 0 0 -2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11/08 17:39:23:984

That is very interesting indeed, because even if the packet is out of order, its sequence number is used, and the next would have to follow correctly without adding a new seq snapshot.... or.... be out of order in such a way that it became reordered.

Edit: If it had been a -1 then I wouldn't expect the above.

Richie.
Last edited by ramdor on Fri Nov 08, 2019 6:07 pm, edited 1 time in total.
w9mdb
Posts: 91
Joined: Sun Apr 09, 2017 5:53 pm

Re: Fun with SEQ Log :-)

Postby w9mdb » Fri Nov 08, 2019 6:04 pm

Where is this seq log?
User avatar
Tony EI7BMB
Posts: 292
Joined: Sun Apr 09, 2017 2:31 pm
Location: Dublin
Contact:

Re: Fun with SEQ Log :-)

Postby Tony EI7BMB » Fri Nov 08, 2019 6:06 pm

I've yet to see anything in the log , am i just lucky or perhaps something else not quite right in my set up I wonder ?
User avatar
ramdor
Posts: 281
Joined: Wed Jul 03, 2019 3:07 pm

Re: Fun with SEQ Log :-)

Postby ramdor » Fri Nov 08, 2019 6:10 pm

Tony EI7BMB wrote:I've yet to see anything in the log , am i just lucky or perhaps something else not quite right in my set up I wonder ?


Don't touch anything Tony :D All perfect by the sounds of it.
User avatar
Tony EI7BMB
Posts: 292
Joined: Sun Apr 09, 2017 2:31 pm
Location: Dublin
Contact:

Re: Fun with SEQ Log :-)

Postby Tony EI7BMB » Fri Nov 08, 2019 6:12 pm

I'll step away from the computer Richie :-)
Bryan W4WMT
Posts: 80
Joined: Sun Apr 09, 2017 10:12 pm

Re: Fun with SEQ Log :-)

Postby Bryan W4WMT » Fri Nov 08, 2019 11:43 pm

Right Richie! It's like the "packet sender" just hit the rewind button, went back two packets, and started over from there :lol:

That must be a firmware fpga glitch!
User avatar
ramdor
Posts: 281
Joined: Wed Jul 03, 2019 3:07 pm

Re: Fun with SEQ Log :-)

Postby ramdor » Sat Nov 09, 2019 12:17 am

So... the wait continues then for some true out of order reports that can be fixed with a re-ordering system 8-)

Richie.
Bryan W4WMT
Posts: 80
Joined: Sun Apr 09, 2017 10:12 pm

Re: Fun with SEQ Log :-)

Postby Bryan W4WMT » Sat Nov 09, 2019 12:46 am

Hi Richie,

Yes, I believe that is correct.
That is, I think a true out-of-order event should have a delta snapshot like this:

0 0 0 1 -2 1 0 0 0...

In this case, the packet sequence would be like this:

1 2 3 5 4 6 7 8 9...

That is, everything is in order except the #4 packet and #5 packet have traded places.
This is the target scenario for Warren's PRO system.
But AFAIK, no one has captured this critter in the SEQ log, yet?

73
Bryan W4WMT
Posts: 80
Joined: Sun Apr 09, 2017 10:12 pm

Re: Fun with SEQ Log :-)

Postby Bryan W4WMT » Sat Nov 09, 2019 10:32 am

From Scott's post in the main 2.6.9 thread:

******************
However, more interestingly, Bryan appears to be the first person to report negative numbers, i.e. packets out of order. So it can and does happen with Thetis as well as PowerSDR. And the numbers are low, just like expected. Therefore it may be worth adding the packet reordering code.
******************

Hi Scott,

I may have captured some negative delta numbers, but not the ones we were looking for. The pattern I am seeing represents repeated packets, not out of order packets. I don't think the PRO can help much with that sort of weirdness!

Nevertheless, I agree, the PRO code should be added. I am getting around to it, albeit slowly. Work is kind of a freakout these days :-(

73
User avatar
w-u-2-o
Posts: 1895
Joined: Fri Mar 10, 2017 1:47 pm

Re: Fun with SEQ Log :-)

Postby w-u-2-o » Sat Nov 09, 2019 12:46 pm

Yup, I'm really starting to hate work, too :lol:
User avatar
ramdor
Posts: 281
Joined: Wed Jul 03, 2019 3:07 pm

Re: Fun with SEQ Log :-)

Postby ramdor » Sat Nov 09, 2019 8:32 pm

However as it stands, I am still waiting for some -ve reports that prove that PRO will actually do something if it was in there ;)

Richie.
Bryan W4WMT
Posts: 80
Joined: Sun Apr 09, 2017 10:12 pm

Re: Fun with SEQ Log :-)

Postby Bryan W4WMT » Sat Nov 09, 2019 9:39 pm

ramdor wrote:However as it stands, I am still waiting for some -ve reports that prove that PRO will actually do something if it was in there ;)

Richie.


That's correct!

Maybe we don't need a "packet reordering" algorithm, so much as we need a "lost packet finding" algorithm :lol:

73
User avatar
ramdor
Posts: 281
Joined: Wed Jul 03, 2019 3:07 pm

Re: Fun with SEQ Log :-)

Postby ramdor » Sat Nov 09, 2019 10:57 pm

Hi Bryan,

Just to confirm your expectations, this is a quick grab of an 'out of order' test, with the option turned on in 'clumsy 0.2'.

outOfOrderExample.PNG
outOfOrderExample.PNG (7.95 KiB) Viewed 1181 times


Richie.
Bryan W4WMT
Posts: 80
Joined: Sun Apr 09, 2017 10:12 pm

Re: Fun with SEQ Log :-)

Postby Bryan W4WMT » Sat Nov 09, 2019 11:58 pm

Yep, that's the signature we're looking for!

Also, patterns like:
0 0 0 2 -2 -2 2 0 0
and
0 0 0 3 -3 0 -3 3 0

Those are the sorts of things the PRO can put back into order, like it never happened.

73
User avatar
W3MMR
Posts: 49
Joined: Thu Jul 11, 2019 8:36 am
Location: Chester, PA
Contact:

Re: Fun with SEQ Log :-)

Postby W3MMR » Mon Nov 11, 2019 12:11 pm

Heres a shot of my log from this morning. Same errors I got yesterday as well. At this time, i was running OBS and making a recording, streaming WebSDR, and had Thetis maximized to 1920x1027. Zero audio glitches, no drop outs, no freeze ups.

seq.PNG
seq.PNG (23.93 KiB) Viewed 1111 times


W3MMR
Studio "A" - Anan 200D, P2 1.8, Thetis 2.6.9, Dell XPS 8700 i7-4770k, Samsung EVO 860 SSD, Nvidia GeForce GTX1050ti, 16GB RAM, Shure SM7B, AL80BX
Studio "B" - Heath-Kit DX100, D-104, National NC-303, Hammarlund HQ-140-X
User avatar
w-u-2-o
Posts: 1895
Joined: Fri Mar 10, 2017 1:47 pm

Re: Fun with SEQ Log :-)

Postby w-u-2-o » Fri Nov 15, 2019 2:08 am

And finally...

Capture.JPG
Capture.JPG (59.96 KiB) Viewed 997 times
w9mdb
Posts: 91
Joined: Sun Apr 09, 2017 5:53 pm

Re: Fun with SEQ Log :-)

Postby w9mdb » Fri Nov 15, 2019 4:17 am

Where is this seq log located?
Bryan W4WMT
Posts: 80
Joined: Sun Apr 09, 2017 10:12 pm

Re: Fun with SEQ Log :-)

Postby Bryan W4WMT » Fri Nov 15, 2019 10:37 am

w-u-2-o wrote:And finally...

Capture.JPG


The dreaded "repeated" packet, aka a "rewind" packet!
Any clue as to what kind of network hijinks can cause something like that Scott???

73
User avatar
W3MMR
Posts: 49
Joined: Thu Jul 11, 2019 8:36 am
Location: Chester, PA
Contact:

Re: Fun with SEQ Log :-)

Postby W3MMR » Fri Nov 15, 2019 11:28 am

w9mdb wrote:Where is this seq log located?


Under the "Tests" tab in the Setup menu...
Studio "A" - Anan 200D, P2 1.8, Thetis 2.6.9, Dell XPS 8700 i7-4770k, Samsung EVO 860 SSD, Nvidia GeForce GTX1050ti, 16GB RAM, Shure SM7B, AL80BX
Studio "B" - Heath-Kit DX100, D-104, National NC-303, Hammarlund HQ-140-X
User avatar
w-u-2-o
Posts: 1895
Joined: Fri Mar 10, 2017 1:47 pm

Re: Fun with SEQ Log :-)

Postby w-u-2-o » Fri Nov 15, 2019 1:55 pm

Bryan W4WMT wrote:
w-u-2-o wrote:And finally...

Capture.JPG


The dreaded "repeated" packet, aka a "rewind" packet!
Any clue as to what kind of network hijinks can cause something like that Scott???

73

The best I can do is re-post Warren's notes from back in Dec 1017. Mind you that this describes a situation and a solution for PowerSDR, not necessarily Thetis, but as the root cause is apparently external to both programs it is likely both programs are susceptible to a greater or lesser degree:

The packet reordering software came about because Manfred, XQ6FOD, collected some data indicating that received packets were occasionally not being processed in the PowerSDR software in the same order that they arrived on the network. I was able to quickly determine that the problem was in the Windows networking software. I don't know if the Windows programmers consider this a bug or a feature; however, what seems to happen is that when more than one packet has been buffered in the Windows software, the most recently received packet is sometimes given to the PowerSDR software first, followed by the older packets. In other words, Windows is not always applying a FIFO (first-in first-out) ordering.

At this point, there were two alternatives: (1) write some simple software to check the order of packets delivered to PowerSDR and reorder them if the ordering is not correct, or (2) explore software such as WinPcap to bypass the Windows network software. None of the programmers has had time to explore (2) in depth, and, I suspect that would lead to some new challenges. So, I wrote some simple software to take approach (1).

It is easy to check the order of the packets since each includes a "sequence number". Re-ordering does add some minimal latency. For example, consider a situation where let's say four packets (0, 1, 2, 3) have arrived at the computer but Windows returns them in the order 3, 0, 1, 2. When the packet re-ordering software sees packet 3, it must buffer it and pass along packets 0, 1, and 2, before it passes along 3. Therefore, we have to add a latency of one packet to be able to correct for one out-of-order packet. Similarly, if we want to correct for multiple out-of-order packets within a certain window of time, we much increase the latency more. This is the reason there is a Latency control in Setup. I'm not sure it ever needs to be set to greater than 1; however, the control is there so we can get some feedback from users and learn about this.

Here are a few other comments about packet reordering:

* It works only for incoming (receive) packets. I do not know if the problem is occurring for "outbound" packets, TX I/Q data and audio. The PowerSDR software has no way to know if those packets are appearing on the network in the same order that they are being sent to Windows. However, IF this is occurring, it could be corrected in the FPGA code by checking the sequence numbers of the outbound packets and reordering appropriately.

* This does NOT fix ALL dropout problems -- they can occur for many reasons when the computer does not have sufficient processing power or when other issues in the system are causing Deferred Procedure Calls. That said, some operators have reported a significant reduction in dropouts from the reordering software.
User avatar
ramdor
Posts: 281
Joined: Wed Jul 03, 2019 3:07 pm

Re: Fun with SEQ Log :-)

Postby ramdor » Fri Nov 15, 2019 2:19 pm

....and still PRO isn't going to do anything for that single -1 when the packet following is the one expected. Ideally, if there is some sort of network issue one would expect an out of order problem somewhere in the following packets, but no, everything is sequenced correctly.

Odd indeed.
w9mdb
Posts: 91
Joined: Sun Apr 09, 2017 5:53 pm

Re: Fun with SEQ Log :-)

Postby w9mdb » Fri Nov 15, 2019 2:29 pm

One other solution would be to use RUDP. But I guess we might not have enough room in the rigs memory to do it?
https://en.wikipedia.org/wiki/Reliable_ ... m_Protocol
Here's a C# implementation
https://github.com/MatthiWare/RUDP.Net
w9mdb
Posts: 91
Joined: Sun Apr 09, 2017 5:53 pm

Re: Fun with SEQ Log :-)

Postby w9mdb » Fri Nov 15, 2019 2:33 pm

I'm guessing these numbers aren't good....I'll see a pattern like this repeated but shifting by one "s#" each time
DCC0
s0=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 243 0 0 0
s1=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 85 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s2=0 0 0 123 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s3=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 118 0 0 0
s4=0 0 0 0 0 0 0 0 0 0 0 0 0 0 784 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s5=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1520 0 0
s6=0 0 0 0 321 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s7=0 0 0 0 0 0 0 0 940 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s8=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 516 0 0 0 0 0 0 0 0 0 0 0
s9=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 517 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s10=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 162 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s11=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 59
s12=0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s13=0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s14=0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s15=0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s16=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 39 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s17=0 0 0 91 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s18=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s19=0 0 23 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

DCC0
s0=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 85 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s1=0 0 0 123 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s2=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 118 0 0 0
s3=0 0 0 0 0 0 0 0 0 0 0 0 0 0 784 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s4=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1520 0 0
s5=0 0 0 0 321 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s6=0 0 0 0 0 0 0 0 940 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s7=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 516 0 0 0 0 0 0 0 0 0 0 0
s8=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 517 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s9=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 162 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s10=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 59
s11=0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s12=0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s13=0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s14=0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s15=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 39 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s16=0 0 0 91 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s17=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s18=0 0 23 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s19=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 752 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

DCC0
s0=0 0 0 123 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s1=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 118 0 0 0
s2=0 0 0 0 0 0 0 0 0 0 0 0 0 0 784 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s3=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1520 0 0
s4=0 0 0 0 321 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s5=0 0 0 0 0 0 0 0 940 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s6=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 516 0 0 0 0 0 0 0 0 0 0 0
s7=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 517 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s8=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 162 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s9=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 59
s10=0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s11=0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s12=0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s13=0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s14=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 39 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s15=0 0 0 91 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s16=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s17=0 0 23 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s18=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 752 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
s19=0 0 0 0 0 0 0 0 0 0 0 0 0 0 63 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
User avatar
w-u-2-o
Posts: 1895
Joined: Fri Mar 10, 2017 1:47 pm

Re: Fun with SEQ Log :-)

Postby w-u-2-o » Fri Nov 15, 2019 5:09 pm

w9mdb: they may be good or bad. If you have a torrent of these reports then it is bad, and indicative of a problem somewhere. The potential problem list is LONG.

If it's just a few now and again and you don't hear anything (pop, clicks, etc.) then it really doesn't matter too much and it's nothing to stress over.
w9mdb
Posts: 91
Joined: Sun Apr 09, 2017 5:53 pm

Re: Fun with SEQ Log :-)

Postby w9mdb » Fri Nov 15, 2019 5:14 pm

How does one know if it's a torrent? There's no time tag on these things.
Does the seq log just keep appending? That wouldn't seem like a good idea unless these sequence problems are very infrequent.
User avatar
ramdor
Posts: 281
Joined: Wed Jul 03, 2019 3:07 pm

Re: Fun with SEQ Log :-)

Postby ramdor » Fri Nov 15, 2019 5:24 pm

A couple of things.

a) you are using version without time stamps, so log is a bit pointless, the s0-s19 could be spread over hours, we cant tell
b) there are no -ve numbers
c) all +ve's signify packet loss, which can be 1e6+1 things
d) a new snapshot drops s19, adds s0, and everything moves down
s0 is the latest
s19 is the oldest
e) the packet delta (received sequence number vs expected) following your large number deltas are 0, which 100% implies that you have packet loss. After that loss everything resumed correctly, you didn't see any of those old packets coming in after the event (would be signified by -ve numbers)

See here : viewtopic.php?f=9&t=3182&start=90#p8975

Richie.

Return to “Thetis”