[Battlemesh] Proposal for battlemesh v10 "testbed"

[Pau]

So instead of fighting protocols we will have fighting firmwares. There
will be many different things among the tests (each firmware might
include a different set of linklayer+routing+apps) that the comparison
among the routing protocol would not be necessary comparable.

In any case, I find it a good idea. What we learned on last WBM is that
there is not a big interest on comparing protocols among the
participants of the event. So maybe comparing firmwares would be more
interesting.

So here my +1

Cheers.

On 13/12/16 21:47, Gui Iribarren wrote:
> Hello battlemeshers,
> during a conversation on the last day of the wbmv10 recognition visit in
> Vienna, while discussing the testbed plan, Simon mentioned that he
> wasn't really personally interested in "battling" protocols so much (as
> in the first few battlemeshes), since noone is doing crazy development
> on the core routing code like in the beginning, and so there's not much
> to show or see.
> i.e. development is on features or edge-case optimizations that don't
> really make a difference in the battlemesh results.
> 
> of course, there's also the problem of the "testbed firmware"...
> 
> So, I proposed to try something different on wbm10!
> 
> there are already out there mesh firmwares implementing each routing
> protocol, being maintained every day, and so up to date with kernel,
> openwrt, and routing protocol versions, etc
> 
> why not use those firmwares?
> i.e. qMp, Gluon, LibreMesh, what else?
> 
> so for example, on day 1 of battlemesh, qMp devs flash everything with
> qMp firm,
> everything works out of the box since they care about that every day of
> the year :)
> qMp devs can explain a bit the features, routing architecture, etc
> and it runs bmx7 so Axel can even run tests on his protocol that day
> 
> next day, gluon devs flash a gluon community firmware (could be
> something done specifically for the event, or just extending an actual
> community).
> again, everything works out of the box, and has a sensible configuration
> of batman-adv
> gluon devs can explain features, config wizard, etc
> batman-adv devs can run tests on their protocol that day
> 
> next day, libremesh devs flash libremesh... rinse and repeat
> 
> not only minimizes chances of total failure,
> but also shifts the focus of attention to actual implementations (mesh
> firmwares), where a big part of the development is happening.
> 
> what would be a good candidate of a firmware being used/maintained in
> the wild, that runs OLSR and/or OLSR2?
> 
> cheers!
> 
> gui
> 
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
> 

-- 
./p4u

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20161214/bdd99bd8/attachment-0001.sig>