Re: [ethersex-devel] Problem with YPort

2015-10-22 Diskussionsfäden Michael Brakemeier 
Hallo Michael,

mit wieviel Ticks/s hast du getestet? Standardeinstellung 50? Dann
sollte auch mit dem neuen Timer Framework das gleiche rauskommen.
Dreh doch bitte mal die "Periodic ticks per second" hoch, Größenordnung
500 Hz oder mehr, und wiederhole den Test.

VG michaelb

Am 22.10.2015 um 23:16 schrieb Michael Späth:
> Hallo!
>
>>> YPort drops incoming packets (Host -> EtherSex) when they are sent too fast.
>> [...]
>>
>> Bist Du sicher, dass Ethersex TCP-Pakete verwirft? Wenn es keine weiteren
>> Daten empfangen kann, sollte das TCP-Receive-Windows auf Null gehen.
> Hier der Wireshark Mitschnitt, zweimal wird 12345 gesendet, zweimal 
> empfangen, zweimal geackt, das dritte Mal verschwindet es im Nirwana (No. 13 
> ist das dritte Paket, No. 14 der Ack, aber es kommt einfach nix mehr 
> zurück...)
>
> Ich habe es mehrfach wiederholt, es sind immer exakt diese Pakete...
>
> Erhöhe ich den Delay zwischen Paketen auf ca. 35msec dann gehen alle ohne 
> Verlust raus...
>
>
> (69 ist der EtherSex Knoten, 81 ein Ubuntu Host):
>
>
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   3 2.411121000192.168.178.81192.168.178.69TCP  
> 74 42582 > 7970 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 
> TSval=844640 TSecr=0 WS=128
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   4 2.41261192.168.178.69192.168.178.81TCP  
> 60 7970 > 42582 [SYN, ACK] Seq=0 Ack=1 Win=330 Len=0 MSS=330
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   5 2.412673000192.168.178.81192.168.178.69TCP  
> 54 42582 > 7970 [ACK] Seq=1 Ack=1 Win=29200 Len=0
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   6 2.412771000192.168.178.81192.168.178.69TCP  
> 59 42582 > 7970 [PSH, ACK] Seq=1 Ack=1 Win=29200 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   7 2.414668000192.168.178.69192.168.178.81TCP  
> 60 [TCP ZeroWindow] 7970 > 42582 [ACK] Seq=1 Ack=6 Win=0 Len=0
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   8 2.423967000192.168.178.69192.168.178.81TCP  
> 60 7970 > 42582 [PSH, ACK] Seq=1 Ack=6 Win=255 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>   9 2.424096000192.168.178.81192.168.178.69TCP  
> 54 42582 > 7970 [ACK] Seq=6 Ack=6 Win=29200 Len=0
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  10 2.424328000192.168.178.81192.168.178.69TCP  
> 59 42582 > 7970 [PSH, ACK] Seq=6 Ack=6 Win=29200 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  11 2.426127000192.168.178.69192.168.178.81TCP  
> 60 [TCP ZeroWindow] 7970 > 42582 [ACK] Seq=6 Ack=11 Win=0 Len=0
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  12 2.443925000192.168.178.69192.168.178.81TCP  
> 60 7970 > 42582 [PSH, ACK] Seq=6 Ack=11 Win=255 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  13 2.444213000192.168.178.81192.168.178.69TCP  
> 59 42582 > 7970 [PSH, ACK] Seq=11 Ack=11 Win=29200 Len=5
>
> Data: 3132333435
> [Length: 5]
>
> No. Time   SourceDestination   Protocol 
> Length Info
>  14 2.445596000192.168.178.69192.168.178.81TCP  
> 60 7970 > 42582 [ACK] Seq=11 Ack=16 Win=255 Len=0
>
>
>
>> Völlig korrekt. Ethersex´ Zeitscheibe ist 20ms. Du könntest mal den Branch
>> new_timer_framework testen. Der zeigt ein deutlich besseres Zeitverhalten.
> Habe ich getestet, passiert das gleiche. Oben ist das Ergebnis dieses 
> Branches.
>
> Ich habe auch den Hop über meinen Gigabit Switch mal eliminiert und direkt 
> angeklemmt -> das gleiche Verhalten.
>
>
> Hat jemand ne Idee wie ich das eventuell anders testen kann? Gibt es dafür 
> Testskripte?
>
>

-- 
Michael Brakemeier
mich...@brakemeier.de


___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel

Re: [ethersex-devel] RFM69

2015-10-22 Diskussionsfäden Meinhard Ritscher 
Hallo,

mal wieder ein Update von der RFM69-Baustelle.

Ich habe mich entschieden, die Bibliothek von LowPowerLab als Grundlage zu 
nehmen. Diese bietet mehr Funktionalitaet, ist aber in C++ fuer die Arduino-
Platform geschrieben.
Anfangs wollte ich die Prortierung so nah wie moeglich am Original halten, um 
upstream-Aenderungen moeglichst einfach uebernehmen zu koennen. Aber dann habe 
ich es aufgegeben, ein digitalWrite etc nachzubauen.
Das Original ist aber noch gut zu erkennen.
Richtig Bauchschmerzen hatten mir Kollisionen auf dem SPI-Bus gemacht. Bis ich 
auf die Idee gekommen bin, dass die Verwendung des SPI innerhalb der 
Interruptbehandlung mit der SPI-Kommunikation des ENC28J60 und des SD-Card-
Readers kollierdiert ...

Der aktuelle Stand: Es laeuft erst einmal. Den Code muss ich aber noch weiter 
aufraeumen.
Wer schon mal schauen will: In den u.g. Branches sind alle Aenderungen drin.

On Tuesday 15 September 2015 23:05:07 Meinhard Ritscher wrote:
> https://github.com/cyc1ingsir/ethersex/tree/prepare_rfm69_pr

> Zu Demonstrationszwecken:
> https://github.com/cyc1ingsir/ethersex/tree/rfm69_receiver_example

Eine Frage noch:
In der Bibliothek wird fuer timeouts gerne auf die Funktion millis() aus der 
Arduino-Welt zurueckgegriffen. Hier zum Beispiel:
uint32_t now = millis();
  while (!rfm69_canSend() && millis() - now < RF69_CSMA_LIMIT_MS)
Um recht nahe am Original zu bleiben, habe ich das so geloest
#include "services/clock/clock.h"
#define millis() (clock_get_uptime())

Gibt es eine aehnliche Funktion zu clock_get_uptime() mit weniger 
Abhaengigkeiten?

Meinhard

___
Ethersex-devel mailing list
Ethersex-devel@list.zerties.org
http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel