Кстати часто встречаю такую конструкцию для копирования буфера известной длинны
while(length--) *dst++ = *src++;
Что это? Копипаст? Почему не использовать что то типа mmcpy? Или надежда на умный компилятор, который все равно заменит на одну команду для процессора?
Не вымерли. Последних лет 5 постоянно работаю с Serial портами. Правда, у меня это больше RS-485.
Но как правило с RS-232, если не требуется работа с линиями RTS, DTR, CTS, DSR, RING, RLSD, то работу с портом можно свести в работе с сокетом. Таких случаев большинство. В таком случае можно воспользоваться и преобразователем RS<->IP и абстрагироваться от COM порта совсем, а работать с TCP сервером.
Так а что мешает держать один скрипт для node-waf. А другой для node-gyp или как оно там будет называться? Сама то логика работы сильно меняться не должна. Что касается libuv/libev так по-моему там все очень подобно и можно ввести дополнительный уровень абстракции на шаблонах например. Впрочем, сам я таким заниматься не готов :-).
Не понял о каких различиях речь? Для v0.4.x ставим старую версию, для v0.6.x новую. Для v0.8 будут свои версии. Новые возможности вниз по версиям распространяться не будут.
Да настройки плеера приходилось ковырять. Результат приемлемый получился. Но осадок остался. Может это еще связано с тем, что использовался Edge Overlap + удаленное управление через VNC, которое тоже грузит шину, еще и более чем видео, потому что в карту картинка идет в разрешении 1920х1080, а обратно уже в полном.
Кстати это тоже проблема — нормальное удаленное управление таким сервером. Работать с ним как с простым компьютером не очень удобно из-за огромного разрешения. Решения с удаленным рабочим столом тоже не очень удобны по причине слабой отзывчивости и опять таки из-за огромного разрешения. У меня есть пара костылей, которые решают эту проблему частично. Но универсального решения нет к сожалению.
Спасибо. Это точно Matrox M9188? Загрузку проца показывать нет смысла — я верю что 16 ядер способны декодировать 10 роликов одновременно. Просто есть опыт использования М9148 — это почти тоже самое. И мне не нравится как на ней воспроизводится видео на весь экран при объединении в видеостену. И проблема там в драйверах или пропускной способности шины. Хоть PCI-Ex x16 — как видно, хватает на 10 роликов.
Черт. Раньше времени отправилось.
Подобные решения от европейских компаний будут подороже — и там покупают. Странно, да?
Вот как раз кучу софта переделать под поддержку «многопроцессорных модулей» будет дороже, чем купить такое решение. Другой вопрос, что 16-24 канала для этого сервера потолок, в то время как существуют решения, которые позволяют расширяться до 60 и даже более 100 каналов. Ну покупать такое только для вывода HDTV видео — глупость. Для видео достаточно поставить матричный коммутатор и прикрутить к панелям правильное управление для коммутации сигналов — это будет намного дешевле. А вот для вывода карт, видео, тех. процесса одновременно со сменой масштаба и места вывода — самое то.
Могу еще покритиковать использование LCD панелей с таким сервером. Видеостена на LCD панелях не годится для вывода технологической информации — их назначение развлекательный, рекламный контент (а для такого контента такой сервер не нужен). Аргументы такие:
1. Неравномерность подсветки у большинства моделей(почти побороли правда).
2. Большое излучение в тепловом диапазоне — постойте хотя бы 5 минут перед такой стеной — почувствуете. А если перед ней надо сидеть 12 часов?
3. Слабая надежность (в аспекте работы 24/7). Долгое время восстановления. Например чтобы достать нижнюю панель из той стойки что изображена на первой картинке нужно демонтировать те три, что находятся над ней, а если стена используется для управления например энергосетью — понятно к чему может привести такой простой.
Intel Core i5 2400 3.1Gghz, но тест идет под виртуалкой VMWare, виртуалке отдано 4 ядра и 1 Гиг памяти.
С одним ядром дает около 7000 rps, но надо учитывать, чо бенчмарк тоже на этой же виртуальной машине работает. Так что выходит одно ядро грузится нодой, а остальные 3 бенчмарком.
ab -c 90 -n 20000 127.0.0.1:1337/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net/
Copyright 2006 The Apache Software Foundation, www.apache.org/
Server Software:
Server Hostname: 127.0.0.1
Server Port: 1337
Document Path: /
Document Length: 12 bytes
Concurrency Level: 90
Time taken for tests: 1.982625 seconds
Complete requests: 20000
Failed requests: 0
Write errors: 0
Total transferred: 1520000 bytes
HTML transferred: 240000 bytes
Requests per second: 10087.64 [#/sec] (mean)
Time per request: 8.922 [ms] (mean)
Time per request: 0.099 [ms] (mean, across all concurrent requests)
Transfer rate: 748.50 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 0 0.3 0 7
Processing: 2 8 1.8 8 18
Waiting: 2 8 1.8 8 18
Total: 2 8 1.8 8 18
Percentage of the requests served within a certain time (ms)
50% 8
66% 8
75% 8
80% 8
90% 9
95% 13
98% 16
99% 16
100% 18 (longest request)
О уже и тут..., а группа nodejs на Google Groups уже второй день гудит от этой статьи.
Кстати, там дали ссылку на «правильное» рекурсивное решение задачки для NodeJS
var app = require('express').createServer();
var fibonacci = function(n, callback) {
var inner = function(n1, n2, i) {
if (i > n) {
callback(null, n2);
return;
}
var func = (i % 100) ? inner : inner_tick;
func(n2, n1 + n2, i + 1);
}
var inner_tick = function(n1, n2, i) {
process.nextTick(function() { inner(n1, n2, i); });
}
if (n == 1 || n == 2) {
callback(null, 1);
} else {
inner(1, 1, 3);
}
}
app.get('/:n', function(req, res) {
fibonacci(req.params.n, function(err, number) {
res.send(''+number);
});
});
app.listen(3000);
Что это? Копипаст? Почему не использовать что то типа mmcpy? Или надежда на умный компилятор, который все равно заменит на одну команду для процессора?
Но как правило с RS-232, если не требуется работа с линиями RTS, DTR, CTS, DSR, RING, RLSD, то работу с портом можно свести в работе с сокетом. Таких случаев большинство. В таком случае можно воспользоваться и преобразователем RS<->IP и абстрагироваться от COM порта совсем, а работать с TCP сервером.
Кстати это тоже проблема — нормальное удаленное управление таким сервером. Работать с ним как с простым компьютером не очень удобно из-за огромного разрешения. Решения с удаленным рабочим столом тоже не очень удобны по причине слабой отзывчивости и опять таки из-за огромного разрешения. У меня есть пара костылей, которые решают эту проблему частично. Но универсального решения нет к сожалению.
Подобные решения от европейских компаний будут подороже — и там покупают. Странно, да?
Вот как раз кучу софта переделать под поддержку «многопроцессорных модулей» будет дороже, чем купить такое решение. Другой вопрос, что 16-24 канала для этого сервера потолок, в то время как существуют решения, которые позволяют расширяться до 60 и даже более 100 каналов. Ну покупать такое только для вывода HDTV видео — глупость. Для видео достаточно поставить матричный коммутатор и прикрутить к панелям правильное управление для коммутации сигналов — это будет намного дешевле. А вот для вывода карт, видео, тех. процесса одновременно со сменой масштаба и места вывода — самое то.
Могу еще покритиковать использование LCD панелей с таким сервером. Видеостена на LCD панелях не годится для вывода технологической информации — их назначение развлекательный, рекламный контент (а для такого контента такой сервер не нужен). Аргументы такие:
1. Неравномерность подсветки у большинства моделей(почти побороли правда).
2. Большое излучение в тепловом диапазоне — постойте хотя бы 5 минут перед такой стеной — почувствуете. А если перед ней надо сидеть 12 часов?
3. Слабая надежность (в аспекте работы 24/7). Долгое время восстановления. Например чтобы достать нижнюю панель из той стойки что изображена на первой картинке нужно демонтировать те три, что находятся над ней, а если стена используется для управления например энергосетью — понятно к чему может привести такой простой.
видео можете выложить с 10х FULL HD на видеостене 4х4?
Кто то пробовал?
Угадайте чему равно a в 1.2.6 и в более поздних релизах.
С одним ядром дает около 7000 rps, но надо учитывать, чо бенчмарк тоже на этой же виртуальной машине работает. Так что выходит одно ядро грузится нодой, а остальные 3 бенчмарком.
ab -c 90 -n 20000 127.0.0.1:1337/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net/
Copyright 2006 The Apache Software Foundation, www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Finished 20000 requests
Server Software:
Server Hostname: 127.0.0.1
Server Port: 1337
Document Path: /
Document Length: 12 bytes
Concurrency Level: 90
Time taken for tests: 1.982625 seconds
Complete requests: 20000
Failed requests: 0
Write errors: 0
Total transferred: 1520000 bytes
HTML transferred: 240000 bytes
Requests per second: 10087.64 [#/sec] (mean)
Time per request: 8.922 [ms] (mean)
Time per request: 0.099 [ms] (mean, across all concurrent requests)
Transfer rate: 748.50 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 0 0.3 0 7
Processing: 2 8 1.8 8 18
Waiting: 2 8 1.8 8 18
Total: 2 8 1.8 8 18
Percentage of the requests served within a certain time (ms)
50% 8
66% 8
75% 8
80% 8
90% 9
95% 13
98% 16
99% 16
100% 18 (longest request)
Кстати, там дали ссылку на «правильное» рекурсивное решение задачки для NodeJS