29.03.2019 Отладка трансивера - весна 2019

Материал из SRNS
Перейти к: навигация, поиск
(2019.04.02 - Новая шина HPP для зеркалирования каналов)
(2019.04.02 - Новая шина HPP для зеркалирования каналов)
Строка 447: Строка 447:
 
Раза в 3 выиграли по времени, но главное - прирост с увеличением числа каналов стал намного меньше. Думаю, порядка 20 мкс на 100 каналов
 
Раза в 3 выиграли по времени, но главное - прирост с увеличением числа каналов стал намного меньше. Думаю, порядка 20 мкс на 100 каналов
  
Немного изучил свойства clock_gettime(). На вызов функции уходит примерно 600 нс, дискрет значения - 18 мкс.  
+
Немного изучил свойства clock_gettime(). На вызов функции уходит примерно ''600 нс, дискрет значения - 18 мкс''.  
 +
 
 +
 
 +
Собрали прошивку под Oryx, на загрузке в 60 каналов по небу виден выигрыш первого маркера в 2 раза:
 +
[[file:20190403_GHPP_Oryx_60ch.png|center]]
  
 
{{wl-publish: 2019-03-29 13:53:44 +0300 | Korogodin }}
 
{{wl-publish: 2019-03-29 13:53:44 +0300 | Korogodin }}

Версия 19:14, 3 апреля 2019

Содержание

Рекомендации по записи экспериментов

Результаты испытаний нужно записывать, чтобы сравнивать текущий результат с тем, что было когда-то и не повторять одинаковые эксперименты.

Желательно записывать следующие данные:

  • дату испытания (в заголовке);
  • номер ревизии PL;
  • номер ревизии PS;
  • экземпляр приемника;
  • условия;
  • цель;
  • ожидаемые результаты;
  • фактические результаты;
  • выводы.

2019.03.29 - Ночной тест MCR1

  • номер ревизии PL: из bin соответствующей ревизии
  • номер ревизии PS: f819e3f0eb58821bf3dba23844136dcc9b294adc с небольшими изменениями (main тактируются процессорным временем вместо плисовского)
  • экземпляр приемника: MCR1 плата 61;
  • условия: антенна на крыше Е;

Приемник проработал ночь, всё ещё трудится. Забито 60 каналов, в F5 около 50 сигналов.

Сообщений от sendMeas о неадекватном времени нет. Но если посмотреть на F5 пакет, то за это время были проблемы:

  • два соседних пакетика в F5 поменяны местами (два раза такое возникло)
  • пропущена одна секунда полностью (один раз)
  • пропущено 8 секунд (один раз) (вроде бы соответствует проблемам с прерываниями на 930 минуте, там между прерываниями вдруг 4 мс)
20190329 MCR1 F5 depdiff.png

Время возникновения проблем в SRNS F5:

SbsL1SD 20: Wrong (big) dt at 737513.051539 day (436453000.000000), dt =  1.999999/ 1.000005
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  5: Wrong (big) dt at 737513.227801 day (451682000.000000), dt =  1.999999/ 1.000005
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->55817.263756 DebugR: 1313134.000000        1000.000000     52.000000
|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 всё ещё сбоит

20190401 MCR1 depF5.png

В GPS опять ложняки по L1CA.

С временем F5 особых проблем нет, только пару раз выпадали на 5 секунд измерения с отдельного спутника (по флагу м.б.).


2019.04.02 - Новая шина HPP для зеркалирования каналов

  • номер ревизии PL: из bin соответствующей ревизии
  • номер ревизии PS: c938d6a9aab0addd1d2974ec135f1749bc22b72d
  • экземпляр приемника: CLONICUS плата 112;
  • условия: антенна на крыше Е;

Иван запилил DMA

Чтение 120 каналов на старой шине GPP:

20190402 GPP 120.png

Полная замена GPP на HPP заставляет нас два раза запускать DMA

20190402 HPPx2 120.png

Если совмещать GPP с HPP: DMA в основном, GPP для повторного чтения времени.

20190402 HPPx1 120.png

Раза в 3 выиграли по времени, но главное - прирост с увеличением числа каналов стал намного меньше. Думаю, порядка 20 мкс на 100 каналов

Немного изучил свойства clock_gettime(). На вызов функции уходит примерно 600 нс, дискрет значения - 18 мкс.


Собрали прошивку под Oryx, на загрузке в 60 каналов по небу виден выигрыш первого маркера в 2 раза:

20190403 GHPP Oryx 60ch.png


[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

Персональные инструменты
Пространства имён

Варианты
Действия
SRNS Wiki
Рабочие журналы
Приватный файлсервер
QNAP Сервер
Инструменты