Subject: Re: [44net] ampr-ripd update 1.14 From: Marius Petrescu marius@yo2loj.ro Date: 09/21/2016 06:59 PM
To: AMPRNet working group 44net@hamradio.ucsd.edu, "Ana C. Custura" ana@netstat.org.uk
On my server running Debian 8 with kernel 3.16.0-4-amd64 it works without the '-r' flag.
I actually wanted to remove that flag, but then it will break the scripts using it.
I will make a new release that ignores that flag but still accepts it as parameter, but runs always in raw mode.
I think this would be the proper approach.
Ok, the multicast mode of course is a good thing, but it has caused some strange behaviour in the past. You could of course keep the old code in there using some #ifdef option for those that want to try it. Or introduce a new flag that switches from raw to multicast mode.
Raw mode always works, but in some cases may have some more CPU overhead. Not sure if it is a noticable difference...
Rob
Actually there is almost no processing overhead involved.
It is just that it gets the whole uscd tunnel traffic instead of the multicasts only and has to filter it by the protocol field, which is very fast. And in basic conditions, that traffic is usually low.
Anyway, I would say: if one wants multicast, then version 1.14 is the one. If not, 1.15 will do.
Marius, YO2LOJ
On 2016-09-21 22:04, Rob Janssen wrote:
(Please trim inclusions from previous messages) _______________________________________________
Subject: Re: [44net] ampr-ripd update 1.14 From: Marius Petrescu marius@yo2loj.ro Date: 09/21/2016 06:59 PM
To: AMPRNet working group 44net@hamradio.ucsd.edu, "Ana C. Custura" ana@netstat.org.uk
On my server running Debian 8 with kernel 3.16.0-4-amd64 it works without the '-r' flag.
I actually wanted to remove that flag, but then it will break the scripts using it.
I will make a new release that ignores that flag but still accepts it as parameter, but runs always in raw mode.
I think this would be the proper approach.
Ok, the multicast mode of course is a good thing, but it has caused some strange behaviour in the past. You could of course keep the old code in there using some #ifdef option for those that want to try it. Or introduce a new flag that switches from raw to multicast mode.
Raw mode always works, but in some cases may have some more CPU overhead. Not sure if it is a noticable difference...
Rob
Actually let me correct that statement, which is wrong:
The only difference is the fact that the raw socket will deliver the complete ethernet frames for all IPIP traffic instead of just the data content of that specific 44.0.0.1 source.
The only overhead is the fact that it needs to compare ip source, destination and ports, instead of relying on the kernel to that operation (the protocol filtering is handled by the kernel in both cases either at socket level in multicast mode or by socket read in raw mode, where protocol 4 is used as a filter, which I think has the same effect).
So unless there is a lot of other IPIP traffic on the machine, there is almost no overhead (4 integer comparation and a pointer operation per IPIP packet - this should be no problem for any modern computer or even an embedded system).
Another side effect is that the tunnel interface will not send IGMP group join messages to ampr-gw, but this is not needed and has no impact at all.
On 2016-09-21 22:36, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Actually there is almost no processing overhead involved.
It is just that it gets the whole uscd tunnel traffic instead of the multicasts only and has to filter it by the protocol field, which is very fast. And in basic conditions, that traffic is usually low.
Anyway, I would say: if one wants multicast, then version 1.14 is the one. If not, 1.15 will do.
Marius, YO2LOJ
On 2016-09-21 22:04, Rob Janssen wrote:
(Please trim inclusions from previous messages) _______________________________________________
Subject: Re: [44net] ampr-ripd update 1.14 From: Marius Petrescu marius@yo2loj.ro Date: 09/21/2016 06:59 PM
To: AMPRNet working group 44net@hamradio.ucsd.edu, "Ana C. Custura" ana@netstat.org.uk
On my server running Debian 8 with kernel 3.16.0-4-amd64 it works without the '-r' flag.
I actually wanted to remove that flag, but then it will break the scripts using it.
I will make a new release that ignores that flag but still accepts it as parameter, but runs always in raw mode.
I think this would be the proper approach.
Ok, the multicast mode of course is a good thing, but it has caused some strange behaviour in the past. You could of course keep the old code in there using some #ifdef option for those that want to try it. Or introduce a new flag that switches from raw to multicast mode.
Raw mode always works, but in some cases may have some more CPU overhead. Not sure if it is a noticable difference...
Rob
How do I unsubscribe?
Change is the end result of all true learning.- Leo Buscaglia
-----Original Message----- From: 44Net [mailto:44net-bounces+arnold.villeneuve=rogers.com@hamradio.ucsd.edu] On Behalf Of Marius Petrescu Sent: September-21-16 3:55 PM To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] ampr-ripd update 1.14
(Please trim inclusions from previous messages) _______________________________________________ Actually let me correct that statement, which is wrong:
The only difference is the fact that the raw socket will deliver the complete ethernet frames for all IPIP traffic instead of just the data content of that specific 44.0.0.1 source.
The only overhead is the fact that it needs to compare ip source, destination and ports, instead of relying on the kernel to that operation (the protocol filtering is handled by the kernel in both cases either at socket level in multicast mode or by socket read in raw mode, where protocol 4 is used as a filter, which I think has the same effect).
So unless there is a lot of other IPIP traffic on the machine, there is almost no overhead (4 integer comparation and a pointer operation per IPIP packet - this should be no problem for any modern computer or even an embedded system).
Another side effect is that the tunnel interface will not send IGMP group join messages to ampr-gw, but this is not needed and has no impact at all.
On 2016-09-21 22:36, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Actually there is almost no processing overhead involved.
It is just that it gets the whole uscd tunnel traffic instead of the multicasts only and has to filter it by the protocol field, which is very fast. And in basic conditions, that traffic is usually low.
Anyway, I would say: if one wants multicast, then version 1.14 is the one. If not, 1.15 will do.
Marius, YO2LOJ
On 2016-09-21 22:04, Rob Janssen wrote:
(Please trim inclusions from previous messages) _______________________________________________
Subject: Re: [44net] ampr-ripd update 1.14 From: Marius Petrescu marius@yo2loj.ro Date: 09/21/2016 06:59 PM
To: AMPRNet working group 44net@hamradio.ucsd.edu, "Ana C. Custura" ana@netstat.org.uk
On my server running Debian 8 with kernel 3.16.0-4-amd64 it works without the '-r' flag.
I actually wanted to remove that flag, but then it will break the scripts using it.
I will make a new release that ignores that flag but still accepts it as parameter, but runs always in raw mode.
I think this would be the proper approach.
Ok, the multicast mode of course is a good thing, but it has caused some strange behaviour in the past. You could of course keep the old code in there using some #ifdef option for those that want to try it. Or introduce a new flag that switches from raw to multicast mode.
Raw mode always works, but in some cases may have some more CPU overhead. Not sure if it is a noticable difference...
Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://hamradio.ucsd.edu/mailman/private/44net/attachments/20160921/ 6e8d6202/attachment.html _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
http://hamradio.ucsd.edu/mailman/listinfo/44net
Check the last option on the page.
On 2016-09-21 23:12, Arnold@rogers wrote:
(Please trim inclusions from previous messages) _______________________________________________ How do I unsubscribe?
Change is the end result of all true learning.- Leo Buscaglia
-
Arnold＠rogers -
Marius Petrescu -
Rob Janssen