Quantcast

last messages

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

last messages

Greg
Never mind with that, I managed to get the svxreflector running and
possible working well, there are udp packet errors in the log regularly
however.. Ports are open tcp and udp on both locations to each other

Thanks
Greg

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: last messages

Tomek
On my side is the same.

czw, 30 mar 2017, 16:35:28: ### SR9SS: UDP frame(s) lost. Expected
seq=55535. Received seq=55536

czw, 30 mar 2017, 16:35:28: ### SR9SS: Dropping out of sequence frame
with seq=55535. Expected seq=55537

But everything works great! We have 12 repeaters connected to
SVXRevlector. Only UDP errors from 2-3 repeaters.

73!

Tom SQ4BJA


W dniu 2017-03-29 o 22:32, Greg pisze:

> Never mind with that, I managed to get the svxreflector running and
> possible working well, there are udp packet errors in the log regularly
> however.. Ports are open tcp and udp on both locations to each other
>
> Thanks
> Greg
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Svxlink-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/svxlink-devel
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: last messages

Rob Janssen
Tomek wrote:

> On my side is the same.
>
> czw, 30 mar 2017, 16:35:28: ### SR9SS: UDP frame(s) lost. Expected
> seq=55535. Received seq=55536
>
> czw, 30 mar 2017, 16:35:28: ### SR9SS: Dropping out of sequence frame
> with seq=55535. Expected seq=55537
>
> But everything works great! We have 12 repeaters connected to
> SVXRevlector. Only UDP errors from 2-3 repeaters.
>
> 73!
>
> Tom SQ4BJA
It looks like you have packet reordering in your network and the software does not handle it.
What kind of network do you have between your systems?  Wireless?  A VPN?

Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: last messages

Tomek
W dniu 2017-03-30 o 17:42, Rob Janssen pisze:

> Tomek wrote:
>> On my side is the same.
>>
>> czw, 30 mar 2017, 16:35:28: ### SR9SS: UDP frame(s) lost. Expected
>> seq=55535. Received seq=55536
>>
>> czw, 30 mar 2017, 16:35:28: ### SR9SS: Dropping out of sequence frame
>> with seq=55535. Expected seq=55537
>>
>> But everything works great! We have 12 repeaters connected to
>> SVXRevlector. Only UDP errors from 2-3 repeaters.
>>
>> 73!
>>
>> Tom SQ4BJA
> It looks like you have packet reordering in your network and the software does not handle it.
> What kind of network do you have between your systems?  Wireless?  A VPN?
>
> Rob
>
>
No, i have optical fiber. And the other repeaters have ethernet
connection to the provider.

478 packets transmitted, 478 received, 0% packet loss, time 477710ms
rtt min/avg/max/mdev = 25.218/26.325/85.857/5.022 ms


SQ4BJA

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: last messages

Rob Janssen
Tomek wrote:
> No, i have optical fiber. And the other repeaters have ethernet
> connection to the provider.
>
> 478 packets transmitted, 478 received, 0% packet loss, time 477710ms
> rtt min/avg/max/mdev = 25.218/26.325/85.857/5.022 ms
>
>
> SQ4BJA

Ok but apparently there is re-ordering.

This can e.g. be caused by queueing or rate limiting, or by accelerated encryption.
For example, the MikroTik CCR multi-core routers have this wellknown issue with IPsec tunnels.
Packets sent to be tunneled are sent off to different cores in the CPU and they may appear
on the output in a different sequence than they were sent to the router.  This will be fixed in
the 6.39 release of RouterOS that is to appear in the coming weeks.

Re-ordering does not mean packet loss.  It means that packets arrive at the destination in a
different sequence than they were sent.  When using a good TCP/IP network stack it does
not affect performance too much, but when using a bad stack (Windows) it causes a lot of
degradation.

When a user program uses UDP it cannot trust the ordering and it would have to resequence
the incoming packets.  Apparently this software does not do that (yet).

The co-channel software I have written has the same issue: it also cannot handle reordering.
However, it sends one packet at a time at a "continuous" rate of about 47 packets per second
or about 21ms between packets, and when this does not cause any bottlenecks there usually
is no re-ordering even when there would be something like the CCR inbetween.
(because the CCR can easily finish handling one packet before the next one arrives)

When UDP packets are sent in bursts without timing, the likelyhood of reordering is much higher.
You could try using a TCP-based VPN (e.g. SSTP or OpenVPN in TCP mode) to see if that fixes
the issue.  However, it is generally a very bad idea to use this type of VPN for anything critical.

Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: last messages

SM0SVX
Hi,

Rob is correct that you are seeing packet reordering. I've never seen it
myself but I've seen what appears to be duplicated packets some times. I
don't know what the cause for that might be (Rob?).

The SvxReflector software handle both these situations by dropping the
out of order packets. The printout you see is not an error message, it's
a debug printout. All printouts starting with ### in SvxLink software
are debug printouts. The SvxReflector is experimental unreleased
software so that's why there are so many debug printouts. When the
SvxReflector software is released the debug printouts will be removed
and details like packet reordering will be handled silently, possibly
keeping statistics over lost and reordered packets.

Reordering of out of sequence packets may be implemented some day but I
feel that the current handling is good enough for the time being. It
should not cause too much problems unless a lot of packets get out of order.

73's de SM0SVX / Tobias

On 2017-03-30 18:28, Rob Janssen wrote:

> Tomek wrote:
>> No, i have optical fiber. And the other repeaters have ethernet
>> connection to the provider.
>>
>> 478 packets transmitted, 478 received, 0% packet loss, time 477710ms
>> rtt min/avg/max/mdev = 25.218/26.325/85.857/5.022 ms
>>
>>
>> SQ4BJA
> Ok but apparently there is re-ordering.
>
> This can e.g. be caused by queueing or rate limiting, or by accelerated encryption.
> For example, the MikroTik CCR multi-core routers have this wellknown issue with IPsec tunnels.
> Packets sent to be tunneled are sent off to different cores in the CPU and they may appear
> on the output in a different sequence than they were sent to the router.  This will be fixed in
> the 6.39 release of RouterOS that is to appear in the coming weeks.
>
> Re-ordering does not mean packet loss.  It means that packets arrive at the destination in a
> different sequence than they were sent.  When using a good TCP/IP network stack it does
> not affect performance too much, but when using a bad stack (Windows) it causes a lot of
> degradation.
>
> When a user program uses UDP it cannot trust the ordering and it would have to resequence
> the incoming packets.  Apparently this software does not do that (yet).
>
> The co-channel software I have written has the same issue: it also cannot handle reordering.
> However, it sends one packet at a time at a "continuous" rate of about 47 packets per second
> or about 21ms between packets, and when this does not cause any bottlenecks there usually
> is no re-ordering even when there would be something like the CCR inbetween.
> (because the CCR can easily finish handling one packet before the next one arrives)
>
> When UDP packets are sent in bursts without timing, the likelyhood of reordering is much higher.
> You could try using a TCP-based VPN (e.g. SSTP or OpenVPN in TCP mode) to see if that fixes
> the issue.  However, it is generally a very bad idea to use this type of VPN for anything critical.
>
> Rob
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Svxlink-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/svxlink-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: last messages

Rob Janssen
Tobias Blomberg wrote:
> Hi,
>
> Rob is correct that you are seeing packet reordering. I've never seen it
> myself but I've seen what appears to be duplicated packets some times. I
> don't know what the cause for that might be (Rob?).

It may be caused by a link-level protocol that does do retransmission
without proper sequencing.   For example, ethernet frames have no sequence
number and are re-transmitted when a collision is detected, and they will result
in a duplicate when there was no actual collision.
That could happen when there is a duplex mismatch, usually the result of setting
one side of the link to fullduplex instead of "auto".
(the other side has to be set to fullduplex as well because the default is halfduplex)

>
> Reordering of out of sequence packets may be implemented some day but I
> feel that the current handling is good enough for the time being. It
> should not cause too much problems unless a lot of packets get out of order.
>
> 73's de SM0SVX / Tobias

You are right, the problem should not be too bad at least when you send out the packets
evenly spaced according to audio timing, not a burst of multiple packets with only
processing inbetween (no wait for audio from a soundcard)

BTW, good to see you again!
I saw you have merged some of Wim's mods for receiver control that we use in our
main repeater.  Did you give any feedback about this?  I asked him but I have no reply
yet, and I would like to know what has been changed that we need to know when
switching from our current modified version to the head of trunk again.

Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Voter PTY (was: last messages)

SM0SVX
On 2017-03-30 19:34, Rob Janssen wrote:
> BTW, good to see you again!
> I saw you have merged some of Wim's mods for receiver control that we use in our
> main repeater.  Did you give any feedback about this?  I asked him but I have no reply
> yet, and I would like to know what has been changed that we need to know when
> switching from our current modified version to the head of trunk again.
If you're talking about the voter PTY you can find all information in
the pull request:

https://github.com/sm0svx/svxlink/pull/193

Or more specifically the following commit:

https://github.com/sm0svx/svxlink/commit/9ece28b247b1bd559905a2652240bc42aabf0e5a

73's de SM0SVX / Tobias

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Voter PTY

Rob Janssen
Tobias Blomberg wrote:

> On 2017-03-30 19:34, Rob Janssen wrote:
>> BTW, good to see you again!
>> I saw you have merged some of Wim's mods for receiver control that we use in our
>> main repeater.  Did you give any feedback about this?  I asked him but I have no reply
>> yet, and I would like to know what has been changed that we need to know when
>> switching from our current modified version to the head of trunk again.
> If you're talking about the voter PTY you can find all information in
> the pull request:
>
> https://github.com/sm0svx/svxlink/pull/193
>
> Or more specifically the following commit:
>
> https://github.com/sm0svx/svxlink/commit/9ece28b247b1bd559905a2652240bc42aabf0e5a
>
> 73's de SM0SVX / Tobias
>

Ok thanks.  Did you test it?
I will have to change our own configs and scripts to adapt to the variable name and commands
but with the above commit diff that should be easy.

We have a "control panel" webpage that allows enable/disable of receivers, kickout of echolink
users etc.  It was written by Wim as well.
(I made a crude version based on my signal info page but he wrote a version with authentication etc)

Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Loading...