Jump to content

    

Alt.F4

Свой
  • Content Count

    1534
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Alt.F4

  • Rank
    Профессионал

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

5925 profile views
  1. Сталкивались с подобным у себя в деревне. У одного опсоса симка изначально в 2G не хочет регаться, пока мобильником не зарегаем в 3G/LTE. Иногда пробивало через часа 4-5 постоянных попыток с ребутом модема. Решения не нашлось, скорее всего опсосы так защищают тарифы для телефонов от м2м, поэтому надо просто тарить м2м тарифы и не забивать голову.
  2. Здравствуйте. Планируем заложить в устройство готовый БП 220В->12В на плату от MeanWell (который уже имеет кучу международных сертификатов). Возник вопрос, какой сертификат нам потребуется делать для продажи устройств через Интернет-магазин в страны ЕАЭС/ЕС? Спасибо.
  3. Какие частоты можно объединить в одной печати? Если в продаже варианты с алиэкпресс, то они всегда где-то рядом или совсем далеко от указанных частот в описании.
  4. Было бы неплохо еще встраиваемые антенны обсудить, кто какие использует, напечатать по всей видимости уже не получится, как для 2G.
  5. Счетчик и xor юзаем с самого начала, думали накинуть еще чего для надежности, но по всей видимости, вариантов и нету..
  6. Да углубляться особо и некуда, в массивах 64-битные числа (UNIX-метки времени в мс), массивы разбиты по суткам, т.е. в одном массиве может быть от 1 до 8.64млн меток в одном массиве, но это критические значения, в среднем порядка 100тыс. в массиве.
  7. controller_m30, нет смысла углубляться в механизм синхронизации, вопрос заключается только в способе расчета КС для неупорядоченных чисел
  8. jcxz, я писал на прошлой странице, что у нас таких данных с метками 100тыс порядка 50тыс и это только суточное разделение, т.е за каждый день накапливается еще столько же. Поэтому слишком дорого держать дополнительные массивы в ОЗУ. По этой же причине мы не можем ничего сортировать. Надо что-то максимально дешевое и максимально точное, чтобы гарантировано позволяло находить отличия в метках данных у разных серверов.
  9. Конечно, там же сдвиги! После 4-часовой объемного коддинга, совсем фильтровать перестал... Как Вам наш первоначальный вариант с умножением на константу и последующим XOR с КС: checksum(cs,num) {return cs^(num*X);} ?
  10. На хабре нашлась статейка на тему контрольной суммы (не совсем понятно почему в ней везде в расчетах КС обозначается как CRC), вот несколько предложенных вариантов для КС 32 бит в разрезе нашей задачи: Метку времени timestamp сразу урезаем до младшего слова 32 бита, т.к. старшие у всех одинаковые, затем умножение на константу, в статье это 0x990C9AB5: cs=cs+(timestamp32*0x990C9AB5); cs=cs^(cs>>16); И второй вариант без умножения: cs=(cs<<5)+cs+timestamp32; cs=(cs<<5)+cs; cs=cs^(cs>>16);
  11. У нас таких массивов порядка 50тыс, дорогое решение держать дополнительные массивы в ОЗУ. Стоит задача оперировать только 32-битной КС. По всей видимости будем писать тесты для выбора лучшего расчета КС с помощью умножения и XOR...
  12. Есть еще такой момент, что при добавлении новой метки нет возможности заново проходить по всему массиву. Т.е. в работе мы оперируем только 32-битной КС, которую рассчитали ранее и по приходу новой метки 64-бита мы должны быстро и максимально дешево обновить КС.
  13. Ruslan1, Вы невнимательно прочли первый пост, почему Вы решили, что там 64 числа? В каждом массиве планируется порядка 100тыс чисел и старшее слово как раз можно отбросить из-за его повторения во всех метках.