|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Всем доброго времени суток. Стоит задача, прокачать через UDP большой поток "некоторых" данных, и записать его на диск. Для того чтобы определить возможности конкретного железа для решения задачи (получения потока данных и записи его на диск). Конкретное железо - это промышленный одноплатный комп, предположительно на атоме. Собственно это было реализовано на C#, с двумя буферами, очередью записи на твердотельный диск, и это все отлично работает на машинах уровня i5 2009 года. Через 4 UDP сокета прокачивается до 500мбит/сек без потерь данных. Когда стали пробовать запускать на атоме (неттоп), выяснилось, что UDP поток начинает начинает резаться. если скорость выше 22мбит/сек на один сокет - появляются потерии и если запускать несколько сокетов - то предел суммарной скорости примерно 85мбит/сек. а нужно 300. Дополнительной обработки в ПО нет, просто принимается пакет, потом в буфер, потом буфер в очередь, потом очередь на диск. Профайлер показывает 93% - это функция Receive. И если выключаю дальнейшую обработку, а только чтение из сокета - те же самые проблемы. То есть тормоза не в "обработке и буферизации" а в том что пакеты на доходят до системной функции Receive. Либо скорость получения из неё буфера - не достаточна. Для эксперимента, пробовал на тот же АТОМ копировать файл через сеть на диск - скорость до 500мбит/сек. То есть как-то же это прокачивается!? Понятно что без буферизации, и скорей всего сразу пишется на диск, но сокеты то принимают такой большой поток. Сперва пробовал делать на асинхронных сокетах Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
потом всякие вариации на синхронном Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
конкретно тот вариант что выше - оказался чуток тормознутей чем асинхронный. Входной буфер сокета пробовал увеличивать до неприличных 100мб - горох об стену. Асинхронный сокет вызывается с каждой датаграммой, что очевидно может притормаживать при большом потоке . Когда я начинал делать варианты с синхронным сокетом, у меня была надежда что можно выгребсти сразу весь системный буфер UDP, но блин каждая Receive возвращает по прежнему по одной датаграмме. Собственно вопросы: 1) Реально ли технически на атоме прокачать через 1..8 UDP сокетов 300мбит/сек без потерь? Или это под силу только TCP? Или нужно поднимать уровень железа до i3 индексом U? 2) Есть ли возможность получать за "шаг" не по одной датаграмме (~1000байт) а выгребать весь входящий UDP буфер. 3) Какие есть хитрые способы работы с сокетами для прокачки больших данных? 4) Мантры линукс и голый "С", в смысле если подобное реализовать на них, UDP сокеты будут работать быстрее и пакеты теряться не будут? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 08:28 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Кифирчик1) Реально ли технически на атоме прокачать через 1..8 UDP сокетов 300мбит/сек без потерь ?ВикипедияТаким образом, UDP предоставляет ненадёжный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не нужны, либо должны исполняться в приложении. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 08:50 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Алексей ККифирчик1) Реально ли технически на атоме прокачать через 1..8 UDP сокетов 300мбит/сек без потерь ?ВикипедияТаким образом, UDP предоставляет ненадёжный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не нужны, либо должны исполняться в приложении. Подловили ) Перефразирую, с потерями не больше 5%. Пока что для 4х сокетов картина маслом такая Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 09:06 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
На С баловался с UDP. Можешь почитать Одного сокета достаточно, по сути 8 сокетов это в 8 раз больше буфер. Надо просто увеличить буфер. Пакеты могут теряться при помещении в буфер отправки, если он переполнен, то они просто игнорируются. Т.е. теряет отправитель. Отправку лучше делать в блокирующем режиме 17346638 , тогда если буфер отправки полный будет ожидание, а не потеря пакета. Тоже самое при приеме. Увеличивай буферы обоих сокетов (отправляющего и принимающего). Второй момент - размер пакета. Он должен быть максимально большим (MTU - 28). Почитай что такое MTU. Если у тебя локалка, то ставь 1472 байта. В гигабите есть Jumbo frame , вроде как 16000 байт максимум, но я с этим не разбирался. Превысишь MTU, начнется дефрагментация пакетов, а это либо тормоза, либо потери. Третий - потери это нормально. Закладывай в свой протокол контроль доставки и повторный запрос потерянного. В локалке потерь мало, а если через инет будешь слать, то там надо скорость регулировать, иначе переполнишь буфер приема какого-нибудь шлюза по дороге и он потеряет хвост твоего "залпа". Четвертый - пакеты могут приходить не в том порядке как отправлены. Вполне возможно получить например в таком порядке 1,2,5,3,4. TCP чем не устроил? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 09:31 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Dima TTCP чем не устроил?+1 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 10:00 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Dima T, Почитал, вижу был очень бурный секс ))) В моем случае, проблема больше не в отправке. В компе который "генерирует" поток я не ограничен, и могу легко 900 мегабит выжать. С MTU - уже тоже ткнулся носом, пакеты до 1400 байт. И рабочий десктоп - принимает пакеты... 900мбит я не считал потери, а на 400 - точно пакет в пакет. С мощными компами - проблем нет. Мне сейчас не нужно делать протокол, или гарантировать порядок. Мне нужно сказать какой по производительности комп нужен чтоб от некоторого оборудования получить поток 300мбит/сек и записать его на диск. UDP я выбрал как более простой вариант, и что это должно быть быстрее по скорости. TCP - будет быстрее передавать? Промышленные компы бывают разные. Можно что-нить типа ordroid взять, а можно Intel Atom, которых там не хилая линейка, разных поколений и с разным количеством ядер/потоков, а можно селерон, а можно i3xxxxU или i5xxxxU или i7xxxxU. И чем мощнее - тем больше потребление и цена. Мне нужно понять где оптимальное решение в моей задаче. То есть задача тестового ПО - определить необходимые характеристики железа. пока что я вижу, что при реализации на .NET - на i5xxxU это шуршит без проблем. на Atom 330 - больше 22 мбит/сек на сокет или более 84мбит/суммарно начинаются потерии... в геометрической прогрессии, табличка в предыдущем посте - для атома. Вопрос - я уперся в производительность железа и надо брать железо мощнее, или я на столько криворукий программист, и есть более быстрые способы ловить пакеты, в частности я предположил что как-то можно не по одному пакету читать а выгребать весь буфер сразу. или (что мне кажется маловероятным) прослойка .NET над системным сокетом вносит такие тормоза и ограничения, и использование "C" в разы все ускорило бы. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 10:21 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
КифирчикUDP я выбрал как более простой вариант, и что это должно быть быстрее по скорости. TCP - будет быстрее передавать? Затести. Возможно быстрее, возможно чуть медленнее. Для простого замера скорости UDP я бы советовал считать объем принятого в секунду и не заморачиваться на потери. Тот топик для баловства поднимал. Просто любопытно было сколько выжму из гигабита. По TCP у меня копирование файла с SSD на SSD идет 103 Мб/сек, т.е. гигабит по TCP, по UDP результаты были скромнее. В инете UDP быстрее, в локалке - сомневаюсь. По сути TCP это и есть UDP плюс решение всех проблем которые я описал. Т.е. в итоге ты напишешь самодельный TCP. КифирчикВопрос - я уперся в производительность железа и надо брать железо мощнее, или я на столько криворукий программист, и есть более быстрые способы ловить пакеты, в частности я предположил что как-то можно не по одному пакету читать а выгребать весь буфер сразу. или (что мне кажется маловероятным) прослойка .NET над системным сокетом вносит такие тормоза и ограничения, и использование "C" в разы все ускорило бы. Читается по одному пакету. Вот криворукость Код: c# 1.
зачем тебе каждый раз новый буфер? Чтобы сборщик мусора почаще запускался? Убери эту строчку из цикла, читай в один и тот же буфер. Думаю использование С тут особо не ускорит. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 10:55 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Dima T, вынос буфера оказал некоторое влияние. но все заметно изменилось, когда я стал делать друг за другом пачку вызовов, упрощенно показано на рисунке ниже Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Потери сократились почти в двое. Что тоже не айс, но если считать что теряется до 10% - то это приемлемо. в планах задумки как оптимизировать bufferManager.Add(ref buff, ref len) и перейти на TCP. И надо бы где-то откопать как работает копирование в протоколе NFS, через который на том же железе запись через сеть разгоняется до 500мбит/сек. Там наверняка какие-нибудь хитрости. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 14:11 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Это зачем тут? Код: c# 1. 2. 3.
buff для чего? Зачем проверка udpClient.Available > 0 ? Определять конец передачи надо где-то в bufferManager.Add() и сбрасывать DoWork. Иначе если передача будет медленно, то ты прочитаешь текущий буфер приема и выпадешь в середине передачи. От того что ты сделал 4 Receive() и 4 bufferManager.Add() суммарно ничего не поменялось, т.к. все равно последовательно обработка идет. Ещи и проблему создал: если будет три пакета принято, то зависнет в ожидании 4-го. Если уж надо избавиться от bufferManager.Add(), то надо делать это в другом потоке. Пул буферов надо создавать: принял, сунул в очередь на обработку, взял следующий, принял и т.д. Для тестов скорости выкинь вообще bufferManager.Add() и оставь один Receive(). Так оценишь максимально возможную скорость приема. PS А эти твои "некоторые" данные это каждый раз новая инфа или слегка измененная старая? Если второе то можно слать только изменения. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 14:52 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Затестил. получатель udp_recv Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43.
отправитель udp_send Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.
Тестил между i5 и i7 по гигабиту. В обе стороны. Скорость 103-105 Мбайт/сек, т.е. чуть быстрее копирования по TCP. Для теста на одном компе запускай udp_recv, на втором udp_send, результаты смотри на принимающей стороне. Код: c# 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 17:00 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Тестить так уж все варианты. Тоже самое по TCP получатель tcp_recv Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38.
отправитель tcp_send Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43.
У меня TCP чуть быстрее получилось. И проц меньше загружает. И букав меньше в коде. Запускать Код: c# 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 18:43 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Ожидаемый результат. Но несмотря на все недостатки UDP у него есть плюсы. Два клиента сидя за НАТами и файрволами могут напрямую обмениваться данными. Это означает быстрое время отклика <1 мс и высокая скорость обмена, до 100 мбит, если оба подключены к одному провайдеру. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 19:21 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Dima TДва клиента сидя за НАТами и файрволами могут напрямую обмениваться данными ... если оба подключены к одному провайдеру. далеко не всегда ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 20:27 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
ИзопропилDima TДва клиента сидя за НАТами и файрволами могут напрямую обмениваться данными ... если оба подключены к одному провайдеру. далеко не всегда не всегда, но не далеко ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2016, 20:33 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Dima TТестить так уж все варианты. Тоже самое по TCP Я смотрю вы прониклись проблемой, и потратили время ))) Дабы усилия не пропали напрасно, я немного адаптировал ваш код, и протестил, результаты в приложенной картинке. Отправлял всегда по 1Гб, пакеты - 1024 байта (для TCP у Dima T пакеты были много больше, по этому думаю скорость не сопоставима с UDP). "Средняя скорость загрузки сети" - подглядывалось на диспетчере задач, я думаю, для UDP - это то на что хватает тяму компу который генерирует поток. Какие будут комментарии? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 11:34 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
КифирчикОтправлял всегда по 1Гб, пакеты - 1024 байта (для TCP у Dima T пакеты были много больше, по этому думаю скорость не сопоставима с UDP). Что за бред? UDP не умеет передавать большие куски, поэтому надо усложнить жизнь TCP. Зачем? Твой "большой поток некоторых данных" что из себя представляет на отправителе? Готовый массив или быстропоявляющиеся куски? Если куски, то какого размера? Надо тестить с условиями приближенными к реальным. Ты же не сферических коней по сети гоняешь, а решаешь конкретную задачу. По UDP можешь послать пакет размером до 65507 и он придет одним пакетом. Только общая скорость будет ниже, потому что на IP уровне он будет разбит на несколько IP пакетов, а после приемки собран обратно. Поэтому идеальный размер пакета для UDP = MTU - 28 (20 байт заголовок IP + 8 заголовок UDP). MTU изернета 1500 поэтому размер 1500 - 28 = 1472 (если по дороге нет VPN туннелей, их заголовки тоже надо вычитать). Самый маленький MTU я встречал 1372. Затести разные размеры UDP пакета и посмотри на скорость. В TCP нет размера пакета, это поток, который при отправке автоматом разбивается на IP пакеты, поэтому чтобы не делать лишних телодвижений и не мешать работать протоколу надо слать сразу как можно больше. Я поставил 65536. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 13:28 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Оба варианта на помойку. Использовать http chunked transfer. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 13:31 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Затестил TCP по 1024, ничего не поменялось. Результаты те же. Нагрузка на проц чуть приподнялась. Расказывай что еще означает "немного адаптировал ваш код" tcp_send по 1024 Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Еще расскажи что за сеть у тебя и сетевое железо. Моделей не надо. Схематично опиши. Я в локалке тестю, через гигабитный свич. Есть подозрение что через инет гоняешь или какое-то взрослое сетевое оборудование, где баллансировка скорости TCP происходит. UDP поэтому и быстрее в инете, т.к. UDP не баллансируется, а либо пролетает быстро, либо вообще не пролетает. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 13:57 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Dima TТвой "большой поток некоторых данных" что из себя представляет на отправителе? Какая-то телеметрия, а как она структурирована и в каком виде будет слаться - я без понятия. Мне сейчас нужно потенциально понять какой для этого ЭВМ нужен, и определить рекомендации каким способом это можно пропихнуть. Размеры пакетов, протоколы - это уже тюнинг которым будут заниматься потом. Я допускаю, что сделав блок для TCP пакета побольше - скорость может подтянуться к UDP. Но не это важно. быстрее UDP скорость не прыгнет в итоге. на "слабом" железе - у UDP адские потери, на "нормальном" - потерь почти нет. Это коррелирует с тормозами которые я получал выше. Вполне достаточно информации для выводов. Если брать встраиваемый компьютер без "нормального" сетевого чипа (как неттопы и ноут с которыми я тестил), то для такого потока нужно что-то более мощное чем i3-370M. А там у всех потребляемая мощность близкая, что у i3 что у i5, порядка 15ватт, можно и i5...U выбирать. Если встраиваемый комп заточен под сетевое применение - то возможно подойдет и атом или селерон, нужно пробовать. Dima TРасказывай что еще означает "немного адаптировал ваш код" tcp_send по 1024 Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62.
Dima TЕще расскажи что за сеть у тебя и сетевое железо. Моделей не надо. Схематично опиши. Два компа стоят рядом, шнурки по 1,5м, свитч DGS-1005G ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 14:45 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
КифирчикДва компа стоят рядом, шнурки по 1,5м, свитч DGS-1005G Странно. Попробуй свич вообще убрать. Соедини компы проводком напрямую. IP-шники не забудь прописать, если они извне раздаются. Как выше писал 19907935 у меня уменьшение до 1024 никак на TCP не повлияло. Еще вопрос: ты где время смотрел? На отправителе или получателе? КифирчикЕсли брать встраиваемый компьютер без "нормального" сетевого чипа (как неттопы и ноут с которыми я тестил), то для такого потока нужно что-то более мощное чем i3-370M. А там у всех потребляемая мощность близкая, что у i3 что у i5, порядка 15ватт, можно и i5...U выбирать. Если встраиваемый комп заточен под сетевое применение - то возможно подойдет и атом или селерон, нужно пробовать. Загрузку проца еще смотри на нем. Все эти маловаттные процы не рассчитаны на долгую высокую нагрузку, чуть поработает в пиковом режиме и начинает замедляться чтобы в отведенные 15 ватт уложиться. Что там за сетевухи. Баловался как-то с CubieBoard , неприятным сюрпризом оказалось что выдавить 100 мбит из сетевухи невозможно, 50 примерно было. Точнее на тот девайс передавал, хранилище бэкапов сделал, думал HDD тупит, а оказалось - сетевуха. А ты гигабит хочешь прогнать. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 15:35 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
КифирчикDima TТвой "большой поток некоторых данных" что из себя представляет на отправителе? Какая-то телеметрия, а как она структурирована и в каком виде будет слаться - я без понятия. Мне сейчас нужно потенциально понять какой для этого ЭВМ нужен, и определить рекомендации каким способом это можно пропихнуть. У тебя этот маломощный девайс на прием или на передачу будет работать? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 15:38 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 15:47 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Dima T, какая-то фантастика на атоме 330м - UDP, пакет 1024 байта + увеличил буфер отправки - скорость поднялась с 233 до 324мбит/сек (замеряю по тому что дошло) - TCP, размер пакета var size = 1024 * 1024 * 2 (вместо size = 1024) - скорость 795мбит... 99м/сек !!!!! Дело именно в размере пакета для TCP, я проверил, вернул обратно - та же скромная скорость порядка 140мбит/сек TCP быстрее, и нагрузка на проц в 2 раза ниже чем UDP о_О на рисунке, график CPU, последний всплеск - TCP, предпоследний UDP в понедельник сделаю замеры на остальных компах авторУ тебя этот маломощный девайс на прием или на передачу будет работать? возможно с него по медленному беспроводному каналу будут что-то загружать (до 10мбит/сек), и если позволят "мощности" данные можно сжимать. авторЕще вопрос: ты где время смотрел? На отправителе или получателе? время на получателе. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 16:04 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
КифирчикавторУ тебя этот маломощный девайс на прием или на передачу будет работать? возможно с него по медленному беспроводному каналу будут что-то загружать (до 10мбит/сек), и если позволят "мощности" данные можно сжимать. А чего тогда на гигабите тестишь? В свойствах сетевухи выстави 10 мбит. Это же совсем другое. У тебя на гигабите твой неттоп просто захлебывается. На 10мбит думаю запаса хватит каким-нибудь deflаte пожать перед отправкой. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 16:28 |
|
Прокачать большой поток через UDP
|
|||
---|---|---|---|
#18+
Dima TКифирчикпропущено... возможно с него по медленному беспроводному каналу будут что-то загружать (до 10мбит/сек), и если позволят "мощности" данные можно сжимать. А чего тогда на гигабите тестишь? В свойствах сетевухи выстави 10 мбит. Это же совсем другое. У тебя на гигабите твой неттоп просто захлебывается. На 10мбит думаю запаса хватит каким-нибудь deflаte пожать перед отправкой. к компу подключено по гигабиту некое оборудование, которое выдает поток до 300мбит/сек и надо его поймать и записать, это основное назначение. как вторичная функция, удаленно с этого компа могут загружать данные по радиоканалу (дополнительный сетевой интерфейс), скорость которого в лучшем случае 10 мбит/сек. и это дополнительная загрузка диска и проца, которая в прочем не существенна. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2016, 16:39 |
|
|
start [/forum/topic.php?fid=20&msg=39349710&tid=1400216]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
57ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 188ms |
0 / 0 |