Про ECC и ошибки (битые торренты)

Делайте выводы

«Самбу» в утилизацию.

при возможности проверь другими модулями памяти. вдруг, от ECC одно название. типа маркетинговый ход.

простые планки памяти просто работают: а с чего они должны были сыпать ошибками?

ну и да, производителей чипов памяти фстудию. не удивлюсь если простая память от Samsung, а ECC от Hynix. ;)

при возможности проверь другими модулями памяти. вдруг, от ECC одно название. типа маркетинговый ход.

Планки с ECC не делают никакой магии, на них тупо или есть «лишняя» микросхема памяти, или ее нет. Все проверки и коррекция происходят в самом процессоре (контроллере памяти).

Делайте выводы.

Какая-то из сторон при работе по сети ленилась проверять контрольные суммы на уровне ethernet.

Тоже вариант, да.

расшарены в сеть самбой

У меня лет 7 назад была точно такая-же проблема. Тоже с utorrent’ом и самбой. ECC не было ни на сервере, ни на венде.

А вот была бы у тебя ЗеЭфЭс...

контрольные суммы на уровне ethernet.

да, 16-битные контрольные суммы - это позор современной сети
эзернет ловит на провод ошибки, и самые удачливые из них (одна на 60 тыс) пишутся в файлы контента
что удивительного в том, что на больших объёмах эти ошибки пролезают?

предположим, что у ОП было 1000 торрент-раздач общим весом 8 Тбайт
10% торрентов - с ошибками
значит, примерно 100 непойманных ошибок
с учётом пойманных было грубо порядка 6 млн ошибок
8 ТБайт / 6 млн ошибок = где-то 1 МБайт / 1 ошибку
это очень хорошая сеть, если там только одна ошибка на 10 миллионов бит
а вот если 1 ошибку на 1 мегабайт допускает оперативка, то это очень плохая оперативка, ты на ней даже винду не запустишь

короче, дело не в «чудесной ЕЦЦ-памяти»

uTorrent

А, заметил, тогда вопросы отпадают. Чего ж нормальными клиентами не пользуетесь?

В принципе, надо попробовать к игровой машине подключить расшаренные виратульной вендой диски и еще раз прогнать перехеширование с игровой машины, по сети. Что мы исключим в этом случае? Точно исключим самбу. Что еще?

Какая модель материнки и процессора? А то я в свою материнку могу ECC память воткнуть, вот только работать она будет в Non-ECC режиме.

Какая-то из сторон при работе по сети ленилась проверять контрольные суммы на уровне ethernet.

Хрена себе, ты самбу переписал, чтоб она прямо через голимый ethernet работала ??

контрольные суммы на уровне ethernet.

да, 16-битные контрольные суммы - это позор современной сети

Ребзя, вам в ПТУ про OSI что-нибудь рассказывал трудовик ?

Ещё вариант - у тебя HDD на машине с виндой сыпятся ошибками (а там куда-то во временный файл на них пишутся данные и портятся). SMART выйдет сегодня погулять в тред или он на самоизоляции?

Хрена себе, ты самбу переписал, чтоб она прямо через голимый ethernet работала ??

На уровне TCP - контрольные суммы 16бит - это точно хуже, чем на уровне ethernet, поэтому я и упомянул ethernet.

А на уровне samba - есть ли они вообще? Большинство приложений где не используется проверка цифровой подписи подразумевает что через сокет проходит без ошибок.

Про уровень smb - https://serverfault.com/questions/946887/smb-cifs-verify-data-integrity

То есть от настроек зависит.

На уровне TCP - контрольные суммы точно хуже, чем на уровне ethernet, поэтому я и упомянул ethernet.

В твоей реальности контрольные суммы существуют либо в ethernet либо в tcp ? Те если ethernet кадр верный, то tcp свою чексумь не проверяет ?

Про уровень smb - https://serverfault.com/questions/946887/smb-cifs-verify-data-integrity

То есть от настроек зависит.

По факту tcp + ethernet дают контрольную сумму в 48бит - довольно много. Если кабель очень плохзой и сажает ошибки в каждом втором пакете, то примерно каждый из 2**48 пакетов он будет пропускать ошибочно. То есть надо пропустить 100 000 ТБайт чтоб словить ошибку на плохом кабеле.

В твоей реальности контрольные суммы существуют либо в ethernet либо в tcp ? Те если ethernet кадр верный, то tcp свою чексумь не проверяет ?

В моей реалности - в софте и железе баги из-за оптимизаций:

Цитирую исходное предположение:

Какая-то из сторон при работе по сети ленилась проверять контрольные суммы на уровне ethernet.

Какая-то из сторон при работе по сети ленилась проверять контрольные суммы на уровне ethernet.

То она отловит ее на уровне tcp :) Ethernet до самбы не дойдет вааще никак...

на уровне tcp увы жалкие 16бит. Вот их реально мало, тут на 100МБ уже при плохом кабеле можно проблему поймать.

А что edac-util -v показывает?

на уровне tcp увы жалкие 16бит. Вот их реально мало, тут на 100МБ уже при плохом кабеле можно проблему поймать

Пля, ты по кабелю гоняешь ethernet или tcp?

Или все же tcp через ethernet?

Про osi все же почитай на летних каникулах, оно в жизни пригодится, чтоб фигню не писать....

mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
edac-util: No errors to report.

теоретически он может задействовать NFSv4 в связке с керберос (если умеет его настраивать). M$ сейчас это поддерживает.