headers
Bruno Randolf | 1 Mar 2005 11:03

Re: LQ code enhancements

hello!

i think there is nothing wrong with calculating the LQ from bigger/combined 
packets - quite in contrary i think this is a good idea. in the end we are 
interrested in the packet loss of *all* packets, especially user traffic 
packets on the link, and not in the packet loss of artificially small HELLO 
packets. 

my assumption is, that user traffic packets will vary in size with a tendency 
to larger, MTU sized, packets, just like the combined OLSR messages in bigger 
networks. as sven-ola already said, the packet loss can be quite different 
for small and large packets, so small HELLOs or even smaller probe packets 
(like in the original ETX paper) might have no loss at all, while 
"normal" (MTU sized) user traffic can have a loss of 100%. in this case i 
would prefer the LQ beeing very low, and this is what we get when we 
calculate the LQ from the bigger combined OLSR messages.

bruno

On Tuesday 01 March 2005 18:43, onelektra wrote:
> Hi!
>
> >> You are shure that was a good idea?
> >
> > Hmmm. Well, my idea (The idea to look at UDP packets and not at the
> > individual messages inside the UDP packets. Not the idea to put more
> > than one message into a single UDP packet.) was inspired by the fact
> > that we thus potentially have more sequence numbers to look at and are
> > able to detect packet loss earlier, possibly before the next HELLO
> > message is due.
(Continue reading)

Permalink | Reply | 1 comment |
headers
onelektra | 1 Mar 2005 14:19
Picon
Gravatar

Re: LQ code enhancements

hello!

> i think there is nothing wrong with calculating the LQ from bigger/combined 
> packets - quite in contrary i think this is a good idea. 

I dont oppose to send bigger packets to measure LQ - that is a really 
good idea.

Of course, having bigger packets show you a loss that is similar to the 
loss of the payload. We were thinking about bigger hello's of a fixed 
size by filling them up to a certain size in the first place.

So that approach is good - you avoid emitting unnecessary traffic to 
create bigger packets if you squeeze other data into it that you have to 
transmit anyway.

But I d suggest not to try calculating/weighting loss against paketsize. 
You may want to do that if you want to find the best packetsize that 
gives you the highest throughput, like TCP does.

I d suggest to measure the loss of packets that have always the *same* 
packetsize, to stay with the KISS approach.

cu elektra
Permalink | Reply | 0 comments |
headers
Sven-Ola Tuecke | 7 Mar 2005 19:58
Picon

Small bugfix for IPIP-Tunnels

Hi Andreas or Thomas,

please add the following bugfix. Just checked this with an ipip tunnel: it 
works (ping and ssh tested). I added a manual Ip4Broadcast to olsrd.conf and 
this patch. Bingo...

Heres the fix, otherwise olsrd complains about not having broadcasts:

--- src/unix/ifnet.c~   Mon Mar  7 19:45:51 2005
+++ src/unix/ifnet.c    Mon Mar  7 19:46:05 2005
 <at>  <at>  -186,7 +186,7  <at>  <at> 

   /* Check broadcast */
   if ((olsr_cnf->ip_version == AF_INET) &&
-      (iface->cnf->ipv4_broadcast.v4) && /* Skip if fixed bcast */
+      !(iface->cnf->ipv4_broadcast.v4) && /* Skip if fixed bcast */
       (!(ifp->int_flags & IFF_BROADCAST)))
     {
       OLSR_PRINTF(3, "\tNo broadcast - removing\n")
 <at>  <at>  -534,7 +534,7  <at>  <at> 

   /* Check broadcast */
   if ((olsr_cnf->ip_version == AF_INET) &&
-      (iface->cnf->ipv4_broadcast.v4) && /* Skip if fixed bcast */
+      !(iface->cnf->ipv4_broadcast.v4) && /* Skip if fixed bcast */
       (!(ifs.int_flags & IFF_BROADCAST)))
     {
       OLSR_PRINTF(debuglvl, "\tNo broadcast - skipping\n")

For those who are interested, here is a simple example setup.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sven-Ola Tuecke | 7 Mar 2005 20:10
Picon

Re: Small bugfix for IPIP-Tunnels

Hi Andreas,

if you need more olsr routings (for debugging or just playing etc), I'am 
happy to offer a temporary ipip tunnel from the berlin mesh to one of your 
machines. We may need to slow down the timers to limit traffic (aaron 
etimated around 4 gig/month with default settings recently - that's a bit 
too much)...

Regards, Sven-Ola
Permalink | Reply | 0 comments |
headers
Andreas Tønnesen | 9 Mar 2005 21:15

olsr.org file download update

Hi all,

I just figured I'd let you know of a update to the file download system
at www.olsr.org as some of you are maintaining automatic build systems
that download source from olsr.org.

When I worked on my master I created a download script to keep track of
the download rate at olsr.org in a easy way. I had planned to remove
this to allow for direct linking to files when my master work was done.
Well, I kind of never got around to it before tonight :) Source and
binary packages can now be browsed at http://www.olsr.org/releases
and all links in the download section are direct file links. the old
download.cgi script is no longer in use.

- Andreas

--

-- 
Andreas Tønnesen
http://www.olsr.org
Permalink | Reply | 2 comments |
headers
Felix Nattermann | 10 Mar 2005 16:06
Picon

Problem with droptime

Hello

I've got a question. I use OLSR 0.4.8 and use it in an ethernet. I emulate a WLAN with iptables over this ethernet. Now I try to use Voice over IP over this MANET. There is one big problem. Changes in the topology of the MANET costs a lot of time until the new route is created. (Up to 15 sec.) I try to change the TC_interval and the Hello_interval, but nothing happens. All pakets are dropped until (after ca. 10 sec) the new route is set.

I hope there is someone who can help me

Felix Nattermann

 
_______________________________________________
olsr-dev mailing list
olsr-dev <at> olsr.org
https://www.olsr.org/mailman/listinfo/olsr-dev
Permalink | Reply | 0 comments |
headers
Felix Nattermann | 12 Mar 2005 15:51
Picon

Problem with droptime

Hello
I've got a question. I use OLSR 0.4.8 and use it in an ethernet. I emulate a 
WLAN with iptables over this ethernet. Now I try to use Voice over IP over 
this MANET. There is one big problem. Changes in the topology of the MANET 
costs a lot of time until the new route is created. (Up to 15 sec.) I try to 
change the TC_interval and the Hello_interval, but nothing happens. All 
pakets are dropped until (after ca. 10 sec) the new route is set.

How can I make OLSR 0.4.8 faster, so that there aren't so many paket-drops?

I hope there is someone who can help me
Felix Nattermann
Permalink | Reply | 8 comments |
headers
Sven-Ola Tuecke | 15 Mar 2005 20:42
Picon

olsrd for nas disk

Hello,

just in case someone else needs this too: heres a binary of olsrd for the 
Allnet ALL6200 / Flepo F6200 NAS Harddisk Drive. Works fine - but no libdl 
on that disk (means: no plugins). You need the zaphod FW in order to run 
binaries too.

http://styx.commando.de/sven-ola/olsrd-all6200.tgz

Rgds, Sven-Ola
Permalink | Reply | 0 comments |
headers
aaron | 16 Mar 2005 10:29
Gravatar

ETX 0.0

hi!

i noticed that sometime the dot_draw plugin shows me an ETX of 0.00
on certiain links. why is that so?
Doe the ETX really have a value of 0?
or is it just the dot_draw output?

If it sometimes really gets 0, whould that not adversely affect the dijkstra
calculations?

best regards,
aaron.

--

-- 
Yesterday it worked.
Today it is not working.
Windows is like that.
              		 (old japanese haiku wisdom)
Permalink | Reply | 1 comment |
headers
Thomas Lopatic | 16 Mar 2005 15:21
Picon

Re: ETX 0.0

Hi Aaron,

Yes, an ETX of 0.00 would be problematic. However, the topology
information is filtered before Dijkstra is run. These links are not taken
into account. 0.00 in the dot_draw plugin simply means "too bad to be
considered". "Too bad" means an ETX of 10000 or more.

-Thomas
Permalink | Reply | 0 comments |

Gmane