Iperf: عرض النطاق الترددي لجهاز الاستقبال لمخرج JSON مفقود لـ UDP

حق. هذا خطأ قديم جدًا ، ربما كان موجودًا في iperf3 منذ البداية. لقد أدركت ذلك نوعًا ما (لماذا لم أقم بتقديم مشكلة لها؟) عندما كنت أقوم بالعمل في # 562. كما أشرت بشكل صحيح ، لا تفصل اختبارات UDP إحصائيات جانب العميل والمتلقي بشكل منفصل. لست متأكدًا مما إذا كان ما تم الإبلاغ عنه هو العميل أو المرسل أو مزيج من الاثنين. كما أنه ليس من الواضح بالنسبة لي سبب اختلاف TCP.

سيكون من الجيد أن تنبعث اختبارات UDP من إحصاءات تشبه إلى حد كبير TCP في هذا الصدد (كلا من جانب المرسل والمستقبل بشكل منفصل) ، على الرغم من أنني لست متأكدًا من كيفية الحفاظ على نوع من التوافق مع البرامج التي تستهلك JSON الحالي انتاج. (في # 562 ، قمت بإصلاح الإخراج الذي يمكن قراءته من قبل الإنسان لـ UDP ، والذي قدمته في مقتطف الإخراج الأول الخاص بك ... كنت أقل قلقًا بشأن التوافق مع الإصدارات السابقة في هذه الحالة لأنه لا ينبغي أن تحاول البرامج قراءة هذا الإخراج على أي حال.)

هل تم إجراء أي حل لهذه المشكلة لإخراج UDP JSON؟ نحن نحاول تحليل إخراج JSON لكننا غير متأكدين مما هو. مثال على إخراج JSON هو: -

    }],
            "sum":  {
                    "start":        0,
                    "end":  10.004644870758057,
                    "seconds":      10.004644870758057,
                    **"bytes":        4364528380,**
                    "bits_per_second":      3484585580.8672519,
                    "jitter_ms":    2.3222640079292773,
                    "lost_packets": 2102766,
                    "packets":      2989403,
                    "lost_percent": 70.34066668160834
            },

لكننا لسنا متأكدين ما هو هذا الشيء البايت ، هل يتم إرساله أم البايتات المستلمة؟

متى سيتم إصلاحه؟ أحتاج إلى الحصول على bps للمستقبل من إخراج JSON.

ربما هناك بعض الحلول؟

إنها ليست على خريطة الطريق الآن. يتطلب إصلاح هذا في الواقع تغييرًا في جهاز الحالة والبروتوكول بين العميل والخادم.

هل لي أن أسأل ... إذا كنت أجري الاختبار باستخدام UDP وقمت بتحليل json من جانب العميل واحصل على

end.sum.bits_per_second     AND 
end.sum.lost_packets

هل سأحصل على تمثيل عادل فيما إذا كان الإرسال يرسل البيانات ويستقبلها من جانب الخادم؟ ما الذي يجب علي فعله للتحقق من نجاح كلا الاتجاهين في الإرسال / الاستلام؟ تحليل إخراج النص من:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.000 ms  0/81 (0%)  sender
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.052 ms  0/81 (0%)  receiver

awardblvr : هذا يعتمد على كيفية end.sum.lost_packets يساوي صفرًا ، فإن جهاز الاستقبال لم يكتشف أي حزم مفقودة. ومع ذلك ، هناك بعض حالات الحافة حول هذا الأمر ، ومعظمها يتعلق بما يحدث للحزم التي لا تزال في حالة طيران عندما يعلن العميل اكتمال الاختبار.

شكرًا ... ، أريد فقط أن أعرف أنه يمكنني قراءة إخراج واحد json وأرى
بشكل أساسي أن الحزم تم نقلها من الخادم -> العميل والحزم
تنتقل من العميل -> وصل الخادم ولم يكن هناك ضياع
الحزم على الحزم التي يتلقاها العميل:

أعتقد أن هذا هو:

end.sum.packets.
end.sum.lost_packets
end.sum_receiver.packets <--- جديد مع التصحيح
end.sum_receiver.lost_packets <--- جديد مع التصحيح

يرجى تصحيح لي إذا كنت مخطئا!

"نهاية": {
"مجموع": {
"النهاية": 10.00،
"ثواني": 10.00،
"بت_في_ثانية": 1058280.26 ،
"بايت": 1322892،
"الحزم": 81،
"البداية": 0 ،
"jitter_ms": 0.056 ،
"lost_packets": 0 ،
"الضائع_النسبة المئوية": 0
} ،
"تيارات": [
{
"udp": {
"النهاية": 10.00،
"المقبس": 5 ،
"ثواني": 10.00،
"بت_في_ثانية": 1058280.26 ،
"بايت": 1322892،
"الحزم": 81،
"out_of_order": 0 ،
"البداية": 0 ،
"jitter_ms": 0.056 ،
"lost_packets": 0 ،
"الضائع_النسبة المئوية": 0
}
}
] ،
"sum_sender": {<--- NEW with PATCH
"النهاية": 10.00،
"ثواني": 10.00،
"بت_في_ثانية": 1058280.26 ،
"بايت": 1322892،
"الحزم": 81،
"البداية": 0 ،
"jitter_ms": 0 ،
"lost_packets": 0 ،
"الضائع_النسبة المئوية": 0
} ،
"sum_receiver": {<--- NEW with PATCH
"النهاية": 10.00،
"ثواني": 10.00،
"بت_في_ثانية": 1058271.16 ،
"بايت": 1322892،
"الحزم": 81،
"البداية": 0 ،
"jitter_ms": 0.0568 ،
"lost_packets": 0 ،
"الضائع_النسبة المئوية": 0
}

شكرا

-أ

يوم الخميس 13 سبتمبر 2018 الساعة 10:04 صباحًا Bruce A. Mah [email protected]
كتب:

awardblvr https://github.com/awardblvr : هذا يعتمد على كيفية قيامك بذلك
تعريف "ناجح". أفترض أن أحد التدابير قد يكون ذلك إذا
قيمة end.sum.lost_packets تساوي صفرًا ، إذًا لم يكتشف جهاز الاستقبال أي ضائع
الحزم. ومع ذلك ، هناك بعض الحالات المتطورة حول هذا الأمر ، والتي يتعين القيام بها في الغالب
مع ما يحدث للحزم التي لا تزال في حالة طيران عند العميل
تعلن اكتمال الاختبار.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/esnet/iperf/issues/584#issuecomment-421079759 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
.

واجهت مشكلة مماثلة مع عدم وجود Tx / Rx B / Ws مستقل لـ UDP.
اتخذ نهجًا مختلفًا.

لقد حسبت RxMbps باستخدام TxRate و Drop٪.

TxMbps = result.Mbps
RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100))

الخادم - 10 ميجابت في الثانية - SRX (الموجه) - 5 ميجابت في الثانية ----- العميل
(تطبيق مؤثرات حركة المرور على واجهات SRX)

أختبر كلا الاتجاهين @ 20 ميجابت في الثانية.

تحميل iPerf3 UDP:

جهاز التحكم عن بعد: 10.8.8.100
محلي: 10.9.9.222
البروتوكول / المنفذ: UDP / 33333
وقت البدء: الأحد ، 10 يناير 2021 03:51:23 بتوقيت جرينتش
المدة (ثانية): 10
معدل الإرسال: 20.0 ميجابت في الثانية
معدل الاستلام: 9.58 ميجابت في الثانية
الارتعاش: 0.7 مللي ثانية
الحزم المفقودة: 8990
النسبة المئوية المفقودة: 52.07٪
وحدة المعالجة المركزية المحلية: 9.03٪
وحدة المعالجة المركزية عن بعد: 0.76٪

تحميل iPerf3 UDP:

جهاز التحكم عن بعد: 10.8.8.100
محلي: 10.9.9.222
البروتوكول / المنفذ: UDP / 33333
وقت البدء: الأحد ، 10 يناير 2021 03:51:38 بتوقيت جرينتش
المدة (ثانية): 10
معدل الإرسال: 20.0 ميجابت في الثانية
معدل الاستلام: 4.82 ميجابت في الثانية
الارتعاش: 0.49 مللي ثانية
الحزم المفقودة: 13172
النسبة المئوية المفقودة: 75.9٪
وحدة المعالجة المركزية المحلية: 2.5٪
وحدة المعالجة المركزية عن بعد: 8.26٪

@ hakujin22 ، "_RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100)) _" من المحتمل ألا تعمل بشكل عام. هذا لأن البيانات يتم جمعها محليًا فقط وليس أيضًا من الطرف البعيد. على سبيل المثال ، في البيانات التي أرسلتها ، يكون عرض النطاق الترددي للربط بين الخادم والعميل هو 5 ميجابت في الثانية. ومع ذلك ، بافتراض أن التحميل هو خادم للعميل ، فإنك تحصل على 10 ميجابت في الثانية على الخادم. هذا لأن هذا هو مقياس الخادم لسرعة نقل البيانات SRX وليس من النهاية إلى النهاية.

@ bmah888 ، نظرًا لأنه يمكن تلقي بيانات الخادم باستخدام --server-output ، يمكن استخدام الطريقة التالية كحل / حل بديل لمشكلة إحصائيات ملخص UDP JSON:

1. ستتم إضافة أقسام JSON "_sum_received_" و "_sum_sent_" إلى ملخص UDP _end_ على كل من الخادم والعميل. وستكون هذه القسم لا تحل محل القسم _sum_.
2. ستتضمن "_sum_received_" بيانات غير صفرية فقط من جهاز استقبال. على سبيل المثال ، سيقوم العميل بتعيينه عند استخدام -R أو ثنائي الاتجاه ، ولكنه سيحدد الصفر عندما يكون المرسل فقط.
3. سيتم تعيين "_sum_sent_" باستخدام قواعد مماثلة ، ولكن للمرسل أو ثنائي الاتجاه.

يبدو أن هذا النهج متوافق مع الإصدارات السابقة للحل الحالي. إذا وافقت ، فقد يكون هذا نهجًا صالحًا وسأحاول تنفيذه.