performance Testprogramm Atmel MAC

[Daniel (Gast)]

Hallo,

ich nutze das Performance Testprogramm der Atmel MAC Software.
Ich übertrage 20000 Pakete bei eingeschalteten Retries und Acks. Bei 
einer schlechten Verbindung kommt es nun dazu, das manchmal 20005 oder 
20001 Pakete emfangen werden, obwohl ja nur 20000 gesendet werden 
sollen. Was kann dafür die Ursache sein? Auch bei wiederholten 
Sendungen, sollte es durch die Sequenznummern zu keiner "doppelten" 
Übertragung kommen. Oder ist der Fehler innerhalb das Prgramms zu 
suchen?

Gruß Daniel

[xyz (Gast)]

Daniel schrieb:
> Oder ist der Fehler innerhalb das Prgramms zu
> suchen?
>
ja in Zeile 42

[Daniel (Gast)]

Wie gesagt, das Programm ist aus der Atmel MAC Software.
Aber ich habe die Main-Datei angehangen, falls es sich jemand anschauen 
möchte. Ich meinte eigenlich ob so etwas im Falle einer schlechten 
Verbindung grundsätzlich entstehen kann. Falls nicht, muss es ja ein 
Programmfehler sein.

[Jörg W. (dl8dtl) (Moderator)]

Daniel schrieb:
> uch bei wiederholten
> Sendungen, sollte es durch die Sequenznummern zu keiner "doppelten"
> Übertragung kommen.

Die Sequenznummer wird ja bei einer Wiederholung nicht erhöht.

Wenn beispielsweise der Rahmen ordnungsgemäß empfangen worden ist,
aber der Absender das ACK nicht gesehen hat, muss er ihn trotzdem
nochmal übertragen.

[Daniel (Gast)]

Ja so habe ich es mir auch vorgestellt. Also muss ein Fehler im Programm 
vorhanden sein. Welcher schwer zu finden sein dürfte...

[Tom M. (tomm)]

Daniel schrieb:
> Ich meinte eigenlich ob so etwas im Falle einer schlechten
> Verbindung grundsätzlich entstehen kann. Falls nicht, muss es ja ein
> Programmfehler sein.

Ja klar, oder denkst du man baut Acks und Retransmits nur zum Spass in 
ein Protokoll ein? 8)

Ich kenn "Atmel MAC" nicht, was ist das für ein Stack bzw. wie sieht die 
PHY aus?

[Daniel (Gast)]

Ist mir schon klar, ich suche nur erst nach Erklärung bevor ich die 
Atmel-
Softwerker beschuldige :-). Der Atmel MAC-Stack wurde nach dem IEEE 
802.15.4 Standard entwickelt.

siehe http://www.atmel.com/dyn/products/tools_card_v2.asp?tool_id=4675

Ich habe mir die entscheidenen Stellen im Code nochmal angeschaut. 
Konnte aber keinen Fehler bei den Zählern finden in den entscheidenen 
Programmteilen. Theoretisch kann es nicht vorkommen, dass mehr Frames 
ankommen als gesendet werden. Merkwürdig...

[Jörg W. (dl8dtl) (Moderator)]

Daniel schrieb:
> Also muss ein Fehler im Programm
> vorhanden sein.

Warum?

Du hast einen Callback für jeden empfangenen Rahmen eingerichtet,
und in diesem zählst du einfach nur hoch, ohne dir irgendwie die
Details des Rahmens anzugucken.

Stell dir nun folgendes Szenario vor: Tln A sendet den Rahmen mit
der Folgenummer 42.  Tln B empfängt ihn, dein Callback wird also
aufgerufen und zählt hoch, Tln B bestätigt ihn.  Die Bestätigung
geht aber verloren, sodass Tln A ihn nochmal sendet.  Dein Callback
wird wiederum aufgerufen, zählt hoch -- schwups, hast du einen zu
viel gezählt.

[Daniel (Gast)]

Achso, ich dachte dass Anhand der gleichen Sequenznummer nur einmal 
hochgezählt wird. Dann hat der Entwickler wohl an dieser Stelle 
gefuscht.

[Daniel (Gast)]

@Jörg
Ich habe das Programm mal folgendermaßen verändert:

void tal_rx_frame_cb(frame_info_t *mac_frame_info, uint8_t lqi)
{
    
  uint8_t Sequence_number = mac_frame_info->seq_num;
  if(Sequence_number!=old_Sequence_number)
  {
    number_rx_frames++;
      aver_lqi += lqi;
  
  }
  old_Sequence_number=Sequence_number;

  

    if (op_mode == PROMISCUOUS_OP_MODE)
    {
        uint8_t i;
        char ascii[5];

        printf("Rx: 0x%.2X ", mac_frame_info->payload_length + 2);  // 2 = FCS
        for (i = 0; i < mac_frame_info->payload_length + 3; i++)    /* 3 = FCS + LQI */
        {
            sprintf(ascii, "%.2X ", mac_frame_info->payload[i]);
            printf(ascii);
        }
        printf("\r\n");
    }

    /* free buffer that was used for frame reception */
    bmm_buffer_free((buffer_t *)(mac_frame_info->buffer_header));
}

Der erste Frame wird wahrscheinlich so noch nicht gezählt, da die erste 
Sequenznummer per Zufall bestimmt wird.

static void configure_frame_sending(void)
{
    uint8_t temp_value[2];

    /*
     * Set TAL PIBs
     * Use: retval_t tal_pib_set(uint8_t attribute, pib_value_t *value);
     */
    temp_value[0] = (uint8_t)SRC_PAN_ID;
    temp_value[1] =  (uint8_t)(SRC_PAN_ID >> 8);
    tal_pib_set(macPANId, (pib_value_t *)&temp_value);

    temp_value[0] = (uint8_t)OWN_SHORT_ADDR;
    temp_value[1] =  (uint8_t)(OWN_SHORT_ADDR >> 8);
    tal_pib_set(macShortAddress, (pib_value_t *)&temp_value);

    temp_value[0] = (uint8_t)DEFAULT_CHANNEL;
    tal_pib_set(phyCurrentChannel, (pib_value_t *)&temp_value);

    /* Init tx frame info structure value that do not change during program execution */
    tx_frame_info = (frame_info_t *)storage_buffer;
    tx_frame_info->msg_type = MCPS_MESSAGE;  // use data frame type for Performance example
    tx_frame_info->seq_num = (uint8_t)rand();
    tx_frame_info->dest_panid = DST_PAN_ID;
    tx_frame_info->dest_address = DST_SHORT_ADDR;
    tx_frame_info->src_panid = SRC_PAN_ID;
    tx_frame_info->src_address = OWN_SHORT_ADDR;
}

Wenn ich einen festen wert für die erste Nummer festlege müsste es gehen 
oder?

Nach einem kleinen Test stimmen die nicht erhaltenen Frames mit nicht 
erhaltenen Acks überein, was natürlich nicht unbedingt heisst dass es 
100%tig funzt.
Reicht diese Veränderung aus, oder siehst du einen groben Fehler?

[Jörg W. (dl8dtl) (Moderator)]

Daniel schrieb:
> Achso, ich dachte dass Anhand der gleichen Sequenznummer nur einmal
> hochgezählt wird.

Du hast doch den Code da, du kannst doch einfach nachgucken, was
gemacht wird.

Die einzige Bedeutung der Folgenummer ist, dass sie im ACK wieder
auftaucht.  Zur wirklichen Identifizierung eines Rahmens taugt
eine einfache 8-bit-Zahl wohl kaum.

> Dann hat der Entwickler wohl an dieser Stelle
> gefuscht.

Du unterstellst einfach viel mehr Funktionalität als hier offenbar
das Entwicklungsziel war.  Dort steht "received frames", und genau
das zählt er auch.

[Jörg W. (dl8dtl) (Moderator)]

Daniel schrieb:
> Reicht diese Veränderung aus

Siehe oben: zur wirklichen eindeutigen Identifizierung eines Rahmens
reicht das nicht.  Du kannst dir mal die kryptografische Authentifi-
zierung im 802.15.4 angucken, die muss sich gegen sogenannte replay-
Attacken absichern und implementiert daher auch eine Folgenummer, die
aber länger ist und die einen Mechanismus implementiert hat, wie sie
bei Überlauf zurückgesetzt wird.

Für deinen einfachen Fall (dem ich allerdings keine ernsthafte
praktische Relevanz zugestehen mag) wird's wohl genügen.