29.03.2019 Отладка трансивера - весна 2019
Korogodin (обсуждение | вклад) (→2019.04.02 - Новая шина HPP для зеркалирования каналов) |
Korogodin (обсуждение | вклад) (→2019.04.02 - Новая шина HPP для зеркалирования каналов) |
||
Строка 452: | Строка 452: | ||
Собрали прошивку под Oryx, на загрузке в 60 каналов по небу виден выигрыш первого маркера в 2 раза: | Собрали прошивку под Oryx, на загрузке в 60 каналов по небу виден выигрыш первого маркера в 2 раза: | ||
[[file:20190403_GHPP_Oryx_60ch.png|center]] | [[file:20190403_GHPP_Oryx_60ch.png|center]] | ||
+ | |||
+ | |||
+ | == 2019.04.04 - Ночной тест MCR1 с HPP == | ||
+ | |||
+ | * номер ревизии PL: собирался Иваном на ~100 каналов, md5sum 0ab4c9f04bdee4adf3301b5cb8e06b25 | ||
+ | * номер ревизии PS: d039b6c4157b00e0bd5c65a4328fdd402eb1f64e | ||
+ | * экземпляр приемника: MCR1 плата 61; | ||
+ | * условия: антенна на крыше Е; | ||
+ | |||
+ | Приемник отработал ночь, всё позитивно. Пропусков F5 нет, есть только невыдача измерений по одному спутнику (ГЛОНАСС 5) в течение 8 секунд. | ||
+ | Есть уже привычные проблемы с GPS и низким уровнем L2/L3. | ||
+ | |||
+ | Код децимации 100 мс main всё ещё сбоит | ||
+ | [[file:20190404_MCR1_HPP_depF5.png|center]] | ||
+ | |||
+ | Тут справа выброс на 100 секунд! Это я начал делать бэкап нашего сервера и нагрузил сеть. | ||
+ | |||
+ | {{Hider|title = 0x0F5 SNR | ||
+ | |content = [[file:20190404_MCR1_HPP_0x0F5_SNR.png|center]] | ||
+ | |hidden = 1 | ||
+ | }} | ||
+ | {{Hider|title = 0x0F5 PR | ||
+ | |content = [[file:20190404_MCR1_HPP_0x0F5_PR.png|center]] | ||
+ | |hidden = 1 | ||
+ | }} | ||
+ | {{Hider|title = 0x0F5 dPRPH | ||
+ | |content = [[file:20190404_MCR1_HPP_0x0F5_dPRPH.png|center]] | ||
+ | |hidden = 1 | ||
+ | }} | ||
+ | {{Hider|title = 0x0F5 Obs | ||
+ | |content = [[file:20190404_MCR1_HPP_0x0F5_Obs.png|center]] | ||
+ | |hidden = 1 | ||
+ | }} | ||
+ | {{Hider|title = 0x002 | ||
+ | |content = [[file:20190404_MCR1_HPP_0x002.png|center]] | ||
+ | |hidden = 1 | ||
+ | }} | ||
+ | |||
{{wl-publish: 2019-03-29 13:53:44 +0300 | Korogodin }} | {{wl-publish: 2019-03-29 13:53:44 +0300 | Korogodin }} |
Версия 11:25, 4 апреля 2019
Содержание[убрать] |
Рекомендации по записи экспериментов
Результаты испытаний нужно записывать, чтобы сравнивать текущий результат с тем, что было когда-то и не повторять одинаковые эксперименты.
Желательно записывать следующие данные:
- дату испытания (в заголовке);
- номер ревизии PL;
- номер ревизии PS;
- экземпляр приемника;
- условия;
- цель;
- ожидаемые результаты;
- фактические результаты;
- выводы.
2019.03.29 - Ночной тест MCR1
- номер ревизии PL: из bin соответствующей ревизии
- номер ревизии PS: f819e3f0eb58821bf3dba23844136dcc9b294adc с небольшими изменениями (main тактируются процессорным временем вместо плисовского)
- экземпляр приемника: MCR1 плата 61;
- условия: антенна на крыше Е;
Приемник проработал ночь, всё ещё трудится. Забито 60 каналов, в F5 около 50 сигналов.
Сообщений от sendMeas о неадекватном времени нет. Но если посмотреть на F5 пакет, то за это время были проблемы:
- два соседних пакетика в F5 поменяны местами (два раза такое возникло)
- пропущена одна секунда полностью (один раз)
- пропущено 8 секунд (один раз) (вроде бы соответствует проблемам с прерываниями на 930 минуте, там между прерываниями вдруг 4 мс)
Время возникновения проблем в SRNS F5:
SbsL1SD 20: Wrong (big) dt at 737513.064016 day (437533000.000000), dt = 1.999999/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.064039 day (437534000.000000), dt = 1.999999/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.222882 day (451261000.000000), dt = 1.999999/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.222905 day (451262000.000000), dt = 1.999999/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.227662 day (451682000.000000), dt = 8.000007/ 1.000005
Время возникновения проблем в BINR F5 (обрабатывался уже через рабочий день, т.е. выборка длиннее):
SbsL1SD 20: Wrong (big) dt at 737513.227801 day (451682000.000000), dt = 1.999999/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.553657 day (479841000.000000), dt = 3.999998/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.553738 day (479849000.000000), dt = 3.999998/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.553819 day (479857000.000000), dt = 3.999998/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.553912 day (479866000.000000), dt = 3.999998/ 1.000005
SbsL1SD 20: Wrong (big) dt at NaN day (479874000.000000), dt = 3.999998/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.554051 day (479882000.000000), dt = 3.999998/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.554225 day (479911000.000000), dt = 3.999998/ 1.000005
SbsL1SD 20: Wrong (big) dt at 737513.554699 day (480085000.000000), dt = 1.999999/ 1.000005
Проблемы совпадают только в момент жесткого лага, когда в SRNS пропущены 8 секунд.
Пропуск 8 секунд
Сообщения об отправке F5 при пропуске 8 секунд выглядели при этом так:
|N1->55818.263793 DebugR: 1313134.000000 1000.000000 52.000000
|N1->55819.263959 DebugR: 1313134.000000 1000.000000 53.000000
|N1->55827.263756 DebugR: 1313134.000000 1000.000000 52.000000
|N1->55828.263959 DebugR: 1313134.000000 1000.000000 52.000000
Между сообщениями о выделении эфемерид до инцидента и после - 30 секунд, так что дело не в currCPUTime. Складывается ощущение, что часть пакетов просто ушла в /dev/null
Переставленные местами пакеты
Опять все выглядит так, будто проблема на уровне Protocol-Pipe-Сеть-Pipe-Protocol.
Дальности и т.п.
Другая проблема - GPS L1C/A. Опять выглядит так, как будто действует имитационная помеха. Либо это внутрисистемные помехи почему-то начали так сильно влиять на нас.
2019.04.01 - Тест MCR1 за выходные
- номер ревизии PL: из bin соответствующей ревизии
- номер ревизии PS: 346f03e3a3a85cbfc17eee665bfcc2bf48bf5258
- экземпляр приемника: MCR1 плата 61;
- условия: антенна на крыше Е;
Приемник проработал выходные, не упал, в целом всё ок. Оператива держится на уровне 71Мб, как при старте. Оба ядра загружены примерно на 75%.
Код децимации 100 мс main всё ещё сбоит
В GPS опять ложняки по L1CA.
С временем F5 особых проблем нет, только пару раз выпадали на 5 секунд измерения с отдельного спутника (по флагу м.б.).
2019.04.02 - Новая шина HPP для зеркалирования каналов
- номер ревизии PL: из bin соответствующей ревизии
- номер ревизии PS: c938d6a9aab0addd1d2974ec135f1749bc22b72d
- экземпляр приемника: CLONICUS плата 112;
- условия: антенна на крыше Е;
Иван запилил DMA
Чтение 120 каналов на старой шине GPP:
Полная замена GPP на HPP заставляет нас два раза запускать DMA
Если совмещать GPP с HPP: DMA в основном, GPP для повторного чтения времени.
Раза в 3 выиграли по времени, но главное - прирост с увеличением числа каналов стал намного меньше. Думаю, порядка 20 мкс на 100 каналов
Немного изучил свойства clock_gettime(). На вызов функции уходит примерно 600 нс, дискрет значения - 18 мкс в случае Oryx на родном Debian.
Собрали прошивку под Oryx, на загрузке в 60 каналов по небу виден выигрыш первого маркера в 2 раза:
2019.04.04 - Ночной тест MCR1 с HPP
- номер ревизии PL: собирался Иваном на ~100 каналов, md5sum 0ab4c9f04bdee4adf3301b5cb8e06b25
- номер ревизии PS: d039b6c4157b00e0bd5c65a4328fdd402eb1f64e
- экземпляр приемника: MCR1 плата 61;
- условия: антенна на крыше Е;
Приемник отработал ночь, всё позитивно. Пропусков F5 нет, есть только невыдача измерений по одному спутнику (ГЛОНАСС 5) в течение 8 секунд. Есть уже привычные проблемы с GPS и низким уровнем L2/L3.
Код децимации 100 мс main всё ещё сбоит
Тут справа выброс на 100 секунд! Это я начал делать бэкап нашего сервера и нагрузил сеть.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.