Нет, не сходится.
На камерах подписано UVAO, VAO… (по округам).
Не подходят ни номер в json, ни номер из строки с самой камеры, которая в верхнем левом углу.
Вот если бы вдруг оказалось, что в url хеш совсем не хеш…
Обзор хороший, но фирма позорная.
Микроскоп, как и большая часть их «продукции», легко находится на AliExpress и стоит порядка $70. Т.е. российская там только коробочка, всё остальное китайское, включая софт и непередаваемый запах.
Я сам счастливый обладатель их цифровой камеры для микроскопа C310 NG, такой же китайщины. В моем случае еще и нагло врали про наличие драйверов для Linux, хотя даже у производителя нет ничего подобного.
Хотел вернуть, но когда почитал, что это невозможно сделать в магазине, а нужно по московским подворотням искать их сервисный центр, понял, что оно того не стоит. В итоге подарил камеру в школу — пусть детишки играются, для лабораторных задач все равно не годилась.
Да, отзывы на их сайте — сплошные сахарные сопли счастливых пользователей, так как все негативные комментарии на следующий день удаляются.
Собственно, я лишь указал на самые заметные из фактических ошибок, которые создают неправильное представление о современном положении дел с TCP. Если же речь в статье только о проблемах старых версий windows, неплохо бы указать это в заголовке.
Фраза про 92-й год о протоколе, а не о его реализации в какой-то операционной системе.
P.S.:
PAWS — не «накладка», а переполнение.
SACK… «положительно или отрицательно» — SACK в TCP использует только положительные подтверждения.
Да и зачем в тегах статьи упомянута замечательная утилита iperf, если в примерах вы используете что-то другое.
Автор плохо разобрался в материале и сеет дезу в массы.
1) Проблему с максимальным размером окна в 64к решили еще в 92-м году, введя в протокол флаг масштабирования окна TCP. Насколько мне известно, Windows штатно поддерживает его начиная с версии 2000.
2) Проблемы с производительностью TCP в LFN-сетях связаны не с превышением размера окна TCP (см. пункт 1), а с медленным темпом «разгона» древних вариантов алгоритмов управления перегрузками TCP до нужного размера окна и их неадекватной реакцией на потери пакетов.
3) Производительность TCP по большей части зависит от алгоритма управления перегрузками на стороне, передающей данные. В не-windows мире серверных систем уже давно используются современные варианты TCP, отлично работающие при большом BDP (например, BIC и CUBIC). Насколько мне известно, Windows начиная с 98 застряла на TCP Reno + SACK, но Compound TCP в 2008-Server призван сократить это отставание.
К слову, для передачи больших объемов данных в сетях с большими задержками используется либо несколько параллельных потоков TCP, либо специальные варианты TCP (HSTCP, HYBLA), либо немножко другие протоколы (см., например, SABUL).
4) Потери пакетов сильно влияют на производительность не потому, что данные приходится передавать повторно — с введением SACK передаются только потерянные сегменты, а не всё окно передачи начиная с первого неподтвержденного байта. На самом деле проблема в том, что потеря даже одного пакета в большинстве старых реализаций TCP (см. пункт 3) интерпретировалась как перегруженность сети, и протокол резко уменьшал окно передачи. В современных вариантах TCP это во многом вылечено.
Поправьте, если ошибаюсь (рассуждаю в рамках школьного курса физики).
Но теплоемкость у воды ~4 кДж/(кг*К), а у воздуха — ~1. Т.е. даже если удастся на выходе из системы повысить температуру воды на 10°С, то чтобы охладить воздух в небольшой комнате на 5°С потребуется объем воды не менее 1/8 комнаты.
Автору на заметку: если в пылесос засунуть мешок с толченым древесным углем (для шашлыков =) и высунуть в форточку шланг, то получается отличный фильтр от дыма и угарного газа. Правда производительность будет низковата и тепловыделение большое. Может посоветуете, как доработать агрегат?
Плохо сформулировал вопрос. Имелось в виду следующее: если я кладу деньги на лк (ввожу номер телефона и пин, т.е. аутентифицируюсь), терминал не выдает чек (частенько бывает), а баланс ЛК после пополнения счета сразу не обновляется (тоже не редкость), есть ли гарантия, что пополнение счета все-таки было зарегистрировано в системе?
Если можете квалифицированно ответить, буду очень признателен.
Противоположная история. Был чек, деньги не пришли. Позвонил в поддержку (примерно в час ночи), милая барышня сверила информацию, после чего перевела платеж на другой мой телефон.
Не надо ругать Wave. Просто ребята из Google решились сделать сложный интерфейс на сырой технологии.
Wave идеологически как раз и есть попытка выйти на новый виток спирали, фундаментальное решение пока не существующей проблемы. Его время просто не пришло.
На камерах подписано UVAO, VAO… (по округам).
Не подходят ни номер в json, ни номер из строки с самой камеры, которая в верхнем левом углу.
Вот если бы вдруг оказалось, что в url хеш совсем не хеш…
Микроскоп, как и большая часть их «продукции», легко находится на AliExpress и стоит порядка $70. Т.е. российская там только коробочка, всё остальное китайское, включая софт и непередаваемый запах.
Я сам счастливый обладатель их цифровой камеры для микроскопа C310 NG, такой же китайщины. В моем случае еще и нагло врали про наличие драйверов для Linux, хотя даже у производителя нет ничего подобного.
Хотел вернуть, но когда почитал, что это невозможно сделать в магазине, а нужно по московским подворотням искать их сервисный центр, понял, что оно того не стоит. В итоге подарил камеру в школу — пусть детишки играются, для лабораторных задач все равно не годилась.
Да, отзывы на их сайте — сплошные сахарные сопли счастливых пользователей, так как все негативные комментарии на следующий день удаляются.
Фраза про 92-й год о протоколе, а не о его реализации в какой-то операционной системе.
P.S.:
Да и зачем в тегах статьи упомянута замечательная утилита iperf, если в примерах вы используете что-то другое.
1) Проблему с максимальным размером окна в 64к решили еще в 92-м году, введя в протокол флаг
масштабирования окна TCP. Насколько мне известно, Windows штатно поддерживает его начиная с версии 2000.
2) Проблемы с производительностью TCP в LFN-сетях связаны не с превышением размера окна TCP (см. пункт 1), а с медленным темпом «разгона» древних вариантов алгоритмов управления перегрузками TCP до нужного размера окна и их неадекватной реакцией на потери пакетов.
3) Производительность TCP по большей части зависит от алгоритма управления перегрузками на стороне, передающей данные. В не-windows мире серверных систем уже давно используются современные варианты TCP, отлично работающие при большом BDP (например, BIC и CUBIC). Насколько мне известно, Windows начиная с 98 застряла на TCP Reno + SACK, но Compound TCP в 2008-Server призван сократить это отставание.
К слову, для передачи больших объемов данных в сетях с большими задержками используется либо несколько параллельных потоков TCP, либо специальные варианты TCP (HSTCP, HYBLA), либо немножко другие протоколы (см., например, SABUL).
4) Потери пакетов сильно влияют на производительность не потому, что данные приходится передавать повторно — с введением SACK передаются только потерянные сегменты, а не всё окно передачи начиная с первого неподтвержденного байта. На самом деле проблема в том, что потеря даже одного пакета в большинстве старых реализаций TCP (см. пункт 3) интерпретировалась как перегруженность сети, и протокол резко уменьшал окно передачи. В современных вариантах TCP это во многом вылечено.
Но теплоемкость у воды ~4 кДж/(кг*К), а у воздуха — ~1. Т.е. даже если удастся на выходе из системы повысить температуру воды на 10°С, то чтобы охладить воздух в небольшой комнате на 5°С потребуется объем воды не менее 1/8 комнаты.
Если можете квалифицированно ответить, буду очень признателен.
Wave идеологически как раз и есть попытка выйти на новый виток спирали, фундаментальное решение пока не существующей проблемы. Его время просто не пришло.