Параллельный рсинк - норм

Параллельный рсинк - норм

это да. но чем?

вообще, всё что использует 1 tcp коннект - это медленно.

Это утверждение становится ложным

вообще, всё что использует 1 tcp коннект - это медленно.

Разработчики http2 не согласятся.

* перестает быть релевантным

Разработчики http2 не согласятся.

да флаг им в руки. факт в том, что несколько tcp-коннектов все-таки лучше.

лучше чем?

для каких целей? в каких условиях?

Это утверждение становится ложным

оно станет ложным, когда в tcp будет какой-то более оптимистичный congestion control

оно станет ложным, когда в tcp будет какой-то более оптимистичный congestion control

Я поправился выше :)

для каких целей? в каких условиях?

две площадки. между ними ~ 120-130ms rtt и периодчески потерьки до 3-7%

можно сколько угодно велосипедить фрейминг и мультиплексирование поверх bytestream, но если этот bytestream медленный - не поможет.

А что не так с запуском? docker run -d -p 6379:6379 -v /var/redis-data:/data --name redis1 redis redis-server /etc/redis/redis.conf --requirepass <...> Выдаёт: *** FATAL CONFIG FILE ERROR *** Reading the configuration file, at line 2 >>> 'protected-mode "no" "/etc/redis/redis.conf"' Bad directive or wrong number of arguments

две площадки. между ними ~ 120-130ms rtt и периодчески потерьки до 3-7%

Вообще, это уже выглядит как edge case. С 7% потерь файло гнать хоть в сколько потоков плохо выйдет.

http://www.psc.edu/index.php/networking/641-tcp-tune

Вообще, это уже выглядит как edge case. С 7% потерь файло гнать хоть в сколько потоков плохо выйдет.

c чего бы вдруг? даже на небольшом проценте потерь tcp начинает печалиться и принимает это всё за congestion

и хорошо, когда ты можешь сменить алгоритм congestion control(cc) на что-то более адекватное(вроде htcp/hybla или cdg)

https://lwn.net/Articles/645115/

две площадки. между ними ~ 120-130ms rtt и периодчески потерьки до 3-7%

Да даже 3% потерь это все

Да даже 3% потерь это все

ну, есть вот гугловый quic

где просто в протокол втащили fec

Кстати да

Мы тестили tcpfec патчи

Мы тестили tcpfec патчи

о, а расскажи

Восстановление после потерь намного быстрее. Но оно имело смысл для коротких сессий, а для длинных все равно тупило

Но там тесты были абсолютно ненаучные :3

тут сейчас выступает чувак coreos. rkt engineer. основная идея которую я пока вынес "мне не хотим магии, поэтому нихрена не сделали. хотите выйти из заатаченнного контейнера? нажмите ctr-] три раза, всего лишь немного магии"

хотите зайти? мы не хотим магии - поэтому сделайте это сами

а есть чонть типа записей/презентацией? Интересует тема с rkt и k8s

записи не будет - интернета нет

я с тезеринга

короче я пока вот прямо вообще не рискну рокит в продакшн

Если вдруг(официальные записи/презентации) удастся раздобыть - скидывай. А в чем проблема? Меня пугает докер и его путь.

rkt кажется сырым, но на верном пути

Если вдруг(официальные записи/презентации) удастся раздобыть - скидывай. А в чем проблема? Меня пугает докер и его путь.

👍

http://go-talks.appspot.com/github.com/s-urbaniak/rkt8s-workshop/workshop.slide

куда приведет путь - хз. но пока они не готовы

Народ подскажите а github - Pull request это запрос новой фичи у автора?

"Yes ... I do use the Linux Desktop 😊" будто это что-то плохое

ну тут все на винде и маках

на линуксе 3 человека

докладчик, его помошник и я

Тебе уже выдали оффер на 250к баксов в месяц?)

А в чем выражается ощущение "они не готовы"?

Опа, опа, готово для десктопа!

Пока мне только кофе выдали и беджик зажали :) На самом деле они тут сказали что эта конференция - первая и тут у всех все в первый раз

rkt - Security (soon) 😞

А в чем выражается ощущение "они не готовы"?

"пока не готова и не знаем когда", "этого нет но вы можете добавить это сами если надо", "ну мы заняты более другими вещами", "мы не хотим магии, но вот вам немного магии, а тут без магии никак"

и тд

Коллеги ) кто гитхабом пользуется подскажите! Pull request - это запрос новой фичи к разработчику?

можно сказать и так

скорее предложение новой фичи, точнее уже готового куска кода для ее реализации

это если совсем на пальцах, не вникая в функциональность git-а

хотя божатся что апи не поменяется

Коллеги ) кто гитхабом пользуется подскажите! Pull request - это запрос новой фичи к разработчику?

Это запрос вытянуть изменения кода из твоего репозитория в его репозиторий.

Хотя вот на битбакете это называется merge request, как по мне так более правильно

> sudo mv bin/acbuild /usr/bin/ ну да, ну да

Что-нибудь про k8s говорят? Насчет production-ready

позже будет. в начале сказали что готов и они его юзают

Это запрос вытянуть изменения кода из твоего репозитория в его репозиторий.

Спасибо понял!

а есть тут кто работавший с CloudLinux?

Допустим есть)

а расскажите тогда, что будет, если забить на регистрацию в CLN?

исходная задача: есть лицензия, прибитая гвоздями к определенному ip range

надо поставить клаудлинукс в абсолютно другом ip range, и исходная лицензия не ставится (фейлится команда rhnreg_ks)

есть мнение, что можно снести пакеты rhn*, а yum репозитории и без того доступны

но есть подозрение, что эта активация тянет за собой что-то еще

ну это как минимум нарушение, работать будет, но это не тру....

есть мануалы по отвязке, в гугле.

ну это как минимум нарушение, работать будет, но это не тру....

сеть приватная, в мир не смотрит, не страшно. это нужно для дебаг-целей, а новый ключ купят хрен пойми когда (сраная бюрократия)

тогда делайте)))

работать точно будет.

так вопрос изначальный был в том, что будет, если просто забить на регистрацию ключа

ничего?

не подскажу) у меня все купленные)))

https://www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf Крайне рекомендуют почитать

схоронил

расскажи потом о чем там :)

скажите, работал кто-нибудь с Tibco EMS?