Re: [44net] ampr-ripd update 1.14

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(a)yo2loj.ro> >>> Date: >>> 09/21/2016 06:59 PM >>> >>> To: >>> AMPRNet working group <44net(a)hamradio.ucsd.edu>du>, "Ana C. Custura" >>> <ana(a)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 >>