[Berlin-wireless] "airtime" RX u/o TX?, war:horst 1.3 prerelease - bitte testen!

[bruno randolf]

hi sven-ola!

hmm, pthreads waere die saubere variante, aber dann wird das binary sicher 
wieder groesser... die von dir vorgeschlagene "immer mal so zwischendrin in 
screen updates packets grabben" variante gefaellt mir ehrlichgesagt gar 
nicht. da muss es eine bessere loesung geben...

ich nehme an der WRT hat einfach nicht genug CPU power und ist zu sehr mit 
screen updates beschaeftigt. wird der packet loss auch nicht besser, wenn du 
den display update wert (-d) vergroessest?

bruno 

On Monday 12 November 2007 16:55:33 Sven-Ola Tücke wrote:
> Moin Bruno,
>
> der genannte Packlosswert war mit "-w 1". Ich stell' mir vor, dass die
> Hauptschleife nicht von recv(mon, ...) angetrieben wird, sondern von
> while(NULL != pbuf) { ... pbuf = pbuf->next } wobei mittendrin immer eine
> Funktion "grabbuffers() { if (recv(mon, ...)) p = malloc(pbuf);allbuf->next
> = p } aufgerufen wird. Immer mal so zwischendrin - irgendwo in die
> Update_Irgendwat()-Funktionen einstreuen. Oder gleich mit pthreads (aber
> das ist dann der Holzhammer)
>
> // Sven-Ola
>
> Am Montag 12 November 2007 08:41:28 schrieb bruno randolf:
> > hi sven-ola!
> >
> > danke! und erstmal nur kurz zu den verlorenen paketen, bis ich zeit habe
> > mir das mit der airtime genau anzusehen: ich habe am PC auch viele pakete
> > verloren bis ich die sleep time im receive loop verkuerzt habe. die kann
> > man mit -w <usec> an der command line veraendern. vielleicht braucht der
> > wrt da noch ne kuerzere zeit. hast du damit rumgespielt? wenn das nicht
> > reicht koennte ich mal select() ausprobieren. lese-puffer waer schoen,
> > aber wie???
> >
> > lg,
> > bruno