Re: [B.A.T.M.A.N.] question about frag_can_reassemble()
Dan, I had a question about the code in frag_can_reassemble(). net/batman-adv/unicast.h 51 52 merged_size = (skb-len - sizeof(*unicast_packet)) * 2; ^^ 53 merged_size += sizeof(struct unicast_packet) + uneven_correction; 54 55 return merged_size = mtu; 56 } Can the skb-len be less than sizeof(*unicast_packet) (ie 20 bytes)? If len is less than 10 then we would return false but if it's over 10 then we would return true. Roughly. the calling function checks for an existing unicast header. The call tree looks like this: recv_ucast_frag_packet() - route_unicast_packet() - frag_can_reassemble() The first function does a unicast length check by calling check_unicast_packet(). As a result we ensure that we at least have the length of the unicast header in our packet unless we overlooked something ? Regards, Marek
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
On Sat, Mar 31, 2012 at 12:11 PM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: On Sat, Mar 31, 2012 at 12:45 PM, Dan Denson danden...@gmail.com wrote: I think I understand. Basically, so long as two interfaces both have a path the to destination of acceptable quality, it will send the packets out the interface that did not receive the packets. Hop count doesn't have a direct effect, we don't really care about hop count, only about link quality. Is that the case? If hop count doesn't really matter, how do I identify my high quality, high capacity backhauls? In batworld, by their high TQ (= AFAIU lack of packet loss to destination.) no capacity involved in the calculations. (but devs might correct me if i'm being too shortsighted!) according to the docs, capacity is not used in the calculation. It is assumed that lowest TQ is always the best route. Hop count adds a default '10' to the TQ which is adjustable. I figure this means that I can give a supernode a lower hop cost than the default 10 which should slide the TQ in favor of using this node as the optimal path. I also infer that this means that picostations running batman-adv that are part of the supernode 'cluster' are going to also add a hop penalty to the TQ. From what I can tell though, link aggregation only cares if a interaces/links have an acceptable TQ, not an equal TQ, though I suspect that two picos in a supernode config would end up providing the same hop count and similar TQ anyway, assuming solid wireless links.
[B.A.T.M.A.N.] any throughput mechanism or plans?
I can't see anything in my reading on this. Is there a mechanism to identify throughput between two nodes? or between a client and a destination for the purpose of routing through the highest throughput path? For instance, track the maximum throughput on each interface over time. Compare it to the current throughput on the interface and send what is leftover as 'available throughput' with the TQ each node. Now instead of adding up the numbers as with TQ, just take the min. Take the lowest throughput along the path and have a node be able to utilize the highest throughput path that has acceptable TQ. As a node's interface gets loaded up (vs observed maximum) it will inform it's neighbors in the same way it informs them of the TQ of each interface and then the neighbors can choose to route around if there is a good alternate path. Basically, I'm thinking that TQ isn't the only or most optimal way to route simply because available throughput should be considered somehow. As far as I can tell, a 56k link with .001% packet loss is better than a 54Mb link with .1% packet loss, though both are solid interfaces and the 54Mb link should be prefered heavily over the 56k link. The 56k link probably will start dropping packets once it is saturated, but one client might run up against slow ACKs keeping the remote server from sending enough data to saturate the connection so the client could be getting a very slow connection while a 54Mb link sits virtually unused.
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
On Sat, Mar 31, 2012 at 04:22:06 -0600, dan wrote: I can't see anything in my reading on this. Is there a mechanism to identify throughput between two nodes? or between a client and a destination for the purpose of routing through the highest throughput path? For instance, track the maximum throughput on each interface over time. Compare it to the current throughput on the interface and send what is leftover as 'available throughput' with the TQ each node. Now instead of adding up the numbers as with TQ, just take the min. Take the lowest throughput along the path and have a node be able to utilize the highest throughput path that has acceptable TQ. As a node's interface gets loaded up (vs observed maximum) it will inform it's neighbors in the same way it informs them of the TQ of each interface and then the neighbors can choose to route around if there is a good alternate path. Basically, I'm thinking that TQ isn't the only or most optimal way to route simply because available throughput should be considered somehow. As far as I can tell, a 56k link with .001% packet loss is better than a 54Mb link with .1% packet loss, though both are solid interfaces and the 54Mb link should be prefered heavily over the 56k link. The 56k link probably will start dropping packets once it is saturated, but one client might run up against slow ACKs keeping the remote server from sending enough data to saturate the connection so the client could be getting a very slow connection while a 54Mb link sits virtually unused. Hello Dan, there is not such mechanism in batman-adv right now. It is a really good idea and we already started to think about that during WBMv5. Personally, I'm applying to the GSOC2012 and I'm proposing something similar. I also think that packet loss is not the correct way to go. Regarding your idea, how would you measure the maximum throughput? Cheers, -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara pgpIpBVDdbZ9q.pgp Description: PGP signature
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
On 03/31/2012 06:03 PM, dan wrote: On Sat, Mar 31, 2012 at 12:11 PM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: On Sat, Mar 31, 2012 at 12:45 PM, Dan Denson danden...@gmail.com wrote: I think I understand. Basically, so long as two interfaces both have a path the to destination of acceptable quality, it will send the packets out the interface that did not receive the packets. Hop count doesn't have a direct effect, we don't really care about hop count, only about link quality. Is that the case? If hop count doesn't really matter, how do I identify my high quality, high capacity backhauls? In batworld, by their high TQ (= AFAIU lack of packet loss to destination.) no capacity involved in the calculations. (but devs might correct me if i'm being too shortsighted!) according to the docs, capacity is not used in the calculation. It is assumed that lowest TQ is always the best route. Hop count adds a default '10' to the TQ which is adjustable. I figure this means that I can give a supernode a lower hop cost than the default 10 which should slide the TQ in favor of using this node as the optimal path. I also infer that this means that picostations running batman-adv that are part of the supernode 'cluster' are going to also add a hop penalty to the TQ. From what I can tell though, link aggregation only cares if a interaces/links have an acceptable TQ, not an equal TQ, though I suspect that two picos in a supernode config would end up providing the same hop count and similar TQ anyway, assuming solid wireless links. it's a tricky task to try and convince batman-adv to favour certain routes. Our strategy in QuintanaLibre has been to lower the hop penalty but also to increase multicast rate where necessary. This effectively invisibilizes some links for batman. You should use this with care, mainly if you are playing with it remotely because you may be left out of a portion of your network. We have reduced hop_penalty to zero on certain preferred nodes and also increased mcast_rate where necessary. Your mcast_rate can actually be heterogeneous across the network. For example, we have an Ubiquiti BulletM2 with a 14db panel antenna which is seen even by the furthest node, which establishes a low rate link that has low throughput but looses very few packets, so batman thinks it's actually a good route when in practice it's not. So we set the Bullet mcast_rate high like so: config 'wifi-iface' option 'device' 'radio0' option 'mcast_rate' '54000' ... and then only those nodes than can establish a really good link to the Bullet will see it as a valid route while others will ignore it. It took a lot of time to find out this subtleties and we don't even know if this is the canonical method but it does work very well to discard undesired low rate routes. In your setup, I think you could increase hop penalty for your picostations, lower the hop penalty for your supernodes and also set their mcast_rate high, so that picostations won't choose to route directly to a far supernode but rather send traffic to their nearest supernode which will have a solid route to the next one... that is if I correctly understood what you are trying to accomplish. Please share your findings on these matters, as we may all profit from each other's experimentation work! Cheers, NicoEchániz
Re: [B.A.T.M.A.N.] [OT] ruci / Was: link alternation when radios are not on batman-adv router?
On 03/31/2012 10:31 PM, Nicolás Echániz wrote: This effectively invisibilizes some links for batman. You should use this with care, mainly if you are playing with it remotely because you may be left out of a portion of your network. One more thing, not specific to batman, but useful for the kind of experimentation you might be doing in the near future. We (QuintanaLibre and DeltaLibre) have designed a tool for fail-proof remote administration of OpenWRT nodes, which Guido (also participating in this thread) has developed and maintains. It's called ruci (for remote uci) and it has many useful features: 1) uses a centralized mercurial repository to store all your nodes configuration. 2) can pull configurations from nodes at any time into the repo. 3) can push configuration changes to a node or set of nodes. 4) can compare configuration status between repo and nodes. 5) can always revert nodes or the whole network to any previous state (provided by mercurial), as long as you keep a useful commit policy. When new configuration is pushed, the remote router updates and reboots (we found this to be safer than just restarting services). It then boots with the new configuration and a 10min. revert timer, which triggers unless you confirm the changes. This simple method provides enormous experimentation possibilities. You can, for example modify your entire network's IP addressing policy in your local configs repo and then push the change simultaneously. If something goes wrong, the routers will revert configuration and reboot in 10 min.; if everythig went well, you can just confirm your changes during the revert window to make them permanent. You don't need to use uci locally, you may just edit config files by hand and push them, but uci really comes in handy to avoid human error when making changes or to implement some modifications programatically. Guido might like to add some more detail, but that's a short description of ruci[0]. Anyone who would like to test it, and might need some initial guidance (mainly to set up things, the rest is self-explanatory), just drop guido or me an e-mail and we will gladly help you out. There's no list or forum yet... Cheers, NicoEchániz [0] http://bitbucket.org/guidoi/ruci
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
Hello Dan, there is not such mechanism in batman-adv right now. It is a really good idea and we already started to think about that during WBMv5. Personally, I'm applying to the GSOC2012 and I'm proposing something similar. I also think that packet loss is not the correct way to go. Regarding your idea, how would you measure the maximum throughput? An easy way might be to just pull the info from ifconfig on a timer: eth0 RX bytes:2841699391 (2.6 GiB) TX bytes:2681928474 (2.4 GiB) + 5 seconds RX bytes:2842069649 (2.6 GiB) TX bytes:2682282969 (2.4 GiB) =RX of 361.5Kb, TX of 346.2Kb just update a value for the MAX of both as they change Compare the stored value to the last 5 second interval so see what amount of the connection is available. In my case, I have a 20Mb/10Mb connection so I have 19.3Mb/9.3Mb available. If I know the connection speed (reliably) then I should be able to statically assign this. Otherwise it should just be based on historical observations. Wireless links are unpredictable so we have to rely on observation while wired or higher end backhaul links are more predictable so it may be best just use a set value. It would be better if we could get total throughput on the wireless link if possible. I would think it would be useful to identify 1/2 duplex vs full duplex. 1/2 duplex should be the aggregate of the rx and tx with some ratio applied (70/30 by default for dl vs ul, this should be tunable) and full duplex wouldn't have a ratio applied.. devices like an SAF freemile or Ubiquiti AirFibre are full duplex, so SAF = 100Mb FD and AirFibre could be 700Mb FD. I am assuming that each node knows which direction is upload and which is download but that might not be true unless the gateway config was used... I'm not sure if that would be another type of advertisement or what.
Re: [B.A.T.M.A.N.] [OT] ruci / Was: link alternation when radios are not on batman-adv router?
2012/3/31 Nicolás Echániz nicoecha...@codigosur.org: on status between repo and nodes. 5) can always revert nodes or the whole network to any previous state (provided by mercurial), as long as you keep a useful commit Thanks for the comments and suggestion. I will definitely check this out. I think I am going to use the mikrotik rb751 flashed to openwrt for the supernode tests. They have 5 ethernet ports that can be addressed individually as well as wireless that I can bridge in for client access. Picostations for the standard nodes and for the radio interfaces on the supernode. I'll do 2.4Ghz for all local meshing and 5Ghz for the links between supernodes and the backhauls.
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
That sounds like a nice start! I'm not sure, though, if that number includes retransmissions and/or unacknowledged frames. IIRC i think i've seen that TX number grow in an interface with such a lossy link that was just sending traffic (trying to reach the distant ap) but getting nothing in return (ap couldn't hear me) So far, with openwrt and ath9k / ath9k_htc, i've found the tx bitrate (or MCS level) a fair indicator of the link capacity. if it says 65.0 MBit/s MCS 7 i cannot tell exactly how much goodput it will have, but i can be pretty confident that it will be better than when it says 6.5 MBit/s MCS 1 Good point on ifconfigs potential limitations. One issue with using the wireless sync rate is that fresnel zone infractions will allow you to sync at one rate but for the link to fall apart as the throughput grows. I have seen a 130Mb link degrade to 54Mb as soon as it started passing significant traffic.
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
On Sat, Mar 31, 2012 at 11:39 PM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: On Sat, Mar 31, 2012 at 11:02 PM, dan danden...@gmail.com wrote: Regarding your idea, how would you measure the maximum throughput? An easy way might be to just pull the info from ifconfig on a timer: eth0 RX bytes:2841699391 (2.6 GiB) TX bytes:2681928474 (2.4 GiB) + 5 seconds RX bytes:2842069649 (2.6 GiB) TX bytes:2682282969 (2.4 GiB) =RX of 361.5Kb, TX of 346.2Kb just update a value for the MAX of both as they change Compare the stored value to the last 5 second interval so see what amount of the connection is available. In my case, I have a 20Mb/10Mb connection so I have 19.3Mb/9.3Mb available. That sounds like a nice start! I'm not sure, though, if that number includes retransmissions and/or unacknowledged frames. Oh, i forgot to add, iw does discriminate between succesfully sent packets, and unsuccessfull retries or failed packets. For example # batctl o -n [B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/56:e6:fc:be:29:d3 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 56:e6:fc:be:26:130.270s (145) 56:e6:fc:b9:b6:48 [ wlan1]: 56:e6:fc:b9:b6:47 (134) 56:e6:fc:b9:b6:48 (145) ### Let's find out how good looks that Nexthop 56:e6:fc:b9:b6:48 on wlan1 # iw wlan1 station get 56:e6:fc:b9:b6:48 Station 56:e6:fc:b9:b6:48 (on wlan1) inactive time: 20 ms rx bytes: 3593056580 rx packets: 2728661 tx bytes: 915427424 tx packets: 1677330 tx retries: 0 tx failed: 0 signal: -71 dBm signal avg: -70 dBm tx bitrate: 72.2 MBit/s MCS 7 short GI rx bitrate: 72.2 MBit/s MCS 7 short GI Those tx bytes do not include retries or failed transmissions, only ACKed packets (AFAIK) of course, making batman peek into this would definitely deviate from the bat-idea of i don't care if physical is wired, wifi, wimax or avian carriers my 2c
