llaann

Я так понимаю человеку надо сейчас решить поблему, а не ждать когда карту купят. До этого времени его юзера съедят. Согласен что лучше купить нормальную карточку, но пока достаточно и этого дожно быть Спасибо всем, буду пробовать. Далее по результатам.

ifconfig eth6 Link encap:Ethernet HWaddr 00:1B:21:B4:15:E5 inet addr:IP-прова Bcast:Bcast-прова Mask:255.255.255.252 inet6 addr: fe80::21b:21ff:feb4:15e5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13498300334 errors:0 dropped:0 overruns:0 frame:0 TX packets:11760102071 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11801620302006 (10.7 TiB) TX bytes:6864146981714 (6.2 TiB) eth7 Link encap:Ethernet HWaddr 00:1B:21:B4:11:A3 inet addr:IP-локалка Bcast:Bcast-локалка Mask:255.255.255.0 inet6 addr: fe80::21b:21ff:feb4:11a3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12698236328 errors:13 dropped:332 overruns:0 frame:7 TX packets:13481928507 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7333694404585 (6.6 TiB) TX bytes:11883083264329 (10.8 TiB) Вывод mpstat 13:38:12 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 13:38:12 all 1,05 0,01 2,76 15,08 1,59 11,23 0,00 0,00 68,28 cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 123 0 0 0 IO-APIC-edge timer 1: 2 0 0 0 IO-APIC-edge i8042 4: 2 0 0 0 IO-APIC-edge 8: 1 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 4 0 0 0 IO-APIC-edge i8042 16: 3879967387 0 0 0 IO-APIC-fasteoi nouveau, eth7 17: 11058 33383175 815438276 75458855 IO-APIC-fasteoi eth6 18: 19 1566642560 44818801 366481023 IO-APIC-fasteoi eth8 19: 2 325 259 227473892 IO-APIC-fasteoi firewire_ohci 23: 98 3331093 58 2014301 IO-APIC-fasteoi ehci_hcd:usb1, ehci_hcd:usb2 24: 2907 0 0 0 HPET_MSI-edge hpet2 25: 0 0 0 0 HPET_MSI-edge hpet3 26: 0 0 0 0 HPET_MSI-edge hpet4 27: 0 0 0 0 HPET_MSI-edge hpet5 35: 20342 66823362 573878 94697594 PCI-MSI-edge ahci 36: 389 0 0 0 PCI-MSI-edge snd_hda_intel 38: 640 4129613 77826 46077 PCI-MSI-edge xhci_hcd 39: 0 0 0 0 PCI-MSI-edge xhci_hcd 40: 0 0 0 0 PCI-MSI-edge xhci_hcd 41: 0 0 0 0 PCI-MSI-edge xhci_hcd 42: 0 0 0 0 PCI-MSI-edge xhci_hcd NMI: 490024 66802 550599 75755 Non-maskable interrupts LOC: 406955270 324282679 337718936 188797266 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 490024 66802 550599 75755 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RES: 1306250 1978783 8101522 4905251 Rescheduling interrupts CAL: 162102 187260 218368 226476 Function call interrupts TLB: 19546522 15351041 33860585 18598245 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 2909 2909 2909 2909 Machine check polls ERR: 0 MIS: 0 сетевухи Intel Corporation 82541PI Gigabit Ethernet Controller

Железо Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, 4 cores Вывод top top - 13:28:43 up 10 days, 2:06, 2 users, load average: 3.16, 3.26, 3.21 Tasks: 246 total, 1 running, 245 sleeping, 0 stopped, 0 zombie Cpu(s): 0.9%us, 4.8%sy, 0.0%ni, 64.3%id, 13.4%wa, 1.8%hi, 14.8%si, 0.0%st Mem: 3905876k total, 2879220k used, 1026656k free, 139464k buffers Swap: 4194296k total, 420408k used, 3773888k free, 369260k cached Счетчики conntrack выставлены на шару sysctl net.nf_conntrack_max net.nf_conntrack_max = 64000000 wc -l /proc/net/nf_conntrack 86621 /proc/net/nf_conntrack

Загрузка при примерно 280 работающих клиентах cat /proc/loadavg 3.25 3.26 3.21 1/335 23732 Входящий канал мониторю именно nload. Т.е. при увеличении работающих клиентов канал почему-то урезается до 200-215 Мбит/с и выше не поднимается, хотя запуская на сервере торрент nload показывает нормальную ширину. Никакие шейперы не используются. Выходит, что либо iptables, либо какие-то счетчики нужно увеличить. Т.к. минуя NAT - все отличто работает.

Здравствуйте, Форумчане! У меня есть шлюз на базе CentOS 6.3 работает как NAT для пользователей, всего их около 500 человек. Входящий канал от магистрала 300 МБит/с. Если с самого сервера качать (например: rtorrent) и мерять nload, то скорость канала на входящем интерфейсе показывает как надо, но если клиент находящийся за NATом начинает замер, то скорость при замере тем-же nload на входящем интерфейсе сервера выше 200 Мбит/с не поднимается. Клиент и сервер связаны через DGS-3627 в гигабите. Переключал канал на клиента, тоже все отлично работает. Пришел к выводу, что NAT режет, но не могу разобраться где именно... Ткните носом где копать, пожалуйста! Заранее спасибо.

А какой именно буфер? Про битрейт это vb=сколько-то?

Вобщем решил проблему передачей в Unicast, вроде завелось. Теперь другая возникла проблема vlc кричит следующее, на клиенте появляются тормоза, рассыпание картинки, и через некоторое время вообще всё тормозит и vlc отключается: Запускаю так:

Запускаю так: Усебя в wireshark'е вижу что поток пошёл. На клиенте ничего не получаю. Пытаюсь у себя принять, также пусто. Может что-то не так делаю.

Как быть-то в данной ситуации, просто первый раз в жизни столкнулся, а решения что-то пока нет. Где можно почитать How-to?

tcpdump на самом сервере показывает: ip ro li даёт следующее, сервер ещё является NAT'ом: Маршрут вроде бы есть, в iptables следующее добавил: Мультикаст должен литься через eth7. Возможно на DGS-3627 надо что-то допилить?

Запускаю так: ffmpeg -fflags genpts -i rtmp://195.20.196.69:1935/tugantel/tugantel -f mpegts -re udp://@224.0.42.1:10191 Выводит следующее: ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers built on Jun 7 2013 18:31:22 with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-3) configuration: --enable-version3 --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvpx --enable-libfaac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libvo-aacenc --enable-libxvid --disable-ffplay --enable-shared --enable-gpl --enable-postproc --enable-nonfree --enable-avfilter --enable-pthreads --extra-cflags=-fPIC --arch=x86_64 libavutil 52. 18.100 / 52. 18.100 libavcodec 54. 92.100 / 54. 92.100 libavformat 54. 63.104 / 54. 63.104 libavdevice 54. 3.103 / 54. 3.103 libavfilter 3. 42.103 / 3. 42.103 libswscale 2. 2.100 / 2. 2.100 libswresample 0. 17.102 / 0. 17.102 libpostproc 52. 2.100 / 52. 2.100 [flv @ 0xb26040] Estimating duration from bitrate, this may be inaccurate Input #0, flv, from 'rtmp://195.20.196.69:1935/tugantel/tugantel': Metadata: author : copyright : description : keywords : rating : title : presetname : Custom creationdate : Thu Jun 20 16:30:44 2013 : videodevice : AVerMedia BDA Analog Capture avclevel : 31 avcprofile : 66 videokeyframe_frequency: 5 audiodevice : ?8=. 2E>4 (Realtek High Definit audiochannels : 1 audioinputvolume: 75 Duration: N/A, start: 0.000000, bitrate: 1601 kb/s Stream #0:0: Video: h264 (Baseline), yuv420p, 720x576 [sAR 1:1 DAR 5:4], 1536 kb/s, 25 tbr, 1k tbn, 50 tbc Stream #0:1: Audio: mp3, 44100 Hz, mono, s16p, 65 kb/s Output #0, mpegts, to 'udp://@224.0.42.1:10191': Metadata: author : copyright : description : keywords : rating : title : presetname : Custom creationdate : Thu Jun 20 16:30:44 2013 : videodevice : AVerMedia BDA Analog Capture avclevel : 31 avcprofile : 66 videokeyframe_frequency: 5 audiodevice : ?8=. 2E>4 (Realtek High Definit audiochannels : 1 audioinputvolume: 75 encoder : Lavf54.63.104 Stream #0:0: Video: mpeg2video, yuv420p, 720x576 [sAR 1:1 DAR 5:4], q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream #0:1: Audio: mp2, 44100 Hz, mono, s16, 128 kb/s Stream mapping: Stream #0:0 -> #0:0 (h264 -> mpeg2video) Stream #0:1 -> #0:1 (mp3 -> mp2) Press [q] to stop, [?] for help frame= 666 fps= 28 q=31.0 Lsize= 3217kB time=00:00:26.65 bitrate= 988.6kbits/s dup=1 drop=60 Что ещё необходимо предоставить?

Приветствую всех! Задача стоит следующая, Есть сервер CentOS 6 там развернут ffmpeg, на нём я принимаю RTMP и хочу отдать его например на udp://@224.0.42.1:10191, его должен принять Chameleon WISI по multicast. Но что-то не получается. Между сервером и WISI есть ещё DGS-3627. Может кто подскажет как организовать стримминг, хотябы ткуть носом в нормальную документацию. Спасибо.

в пиках именно так и смотрю, а насчет провайдера не уверен. По графику nload на интерфейсе бываю скачки до максимума, но именно скачки. а график MRTG - даёт только 115 плюс ко всему после 180-200 клиентов вообще сильно проседает. При тестировании канала без нагрузки всё было в порядке, отсюда и вывод получился, что железка не может справится, но причина не ясна.

Воткнул accel-ppp 1.7.3, как пишут там собрано всё. poptop - убил, как следствие, отвалился шейпер на tc(но это ладно, как-нибудь потом разберёмся), но ситуация по загрузке канала пока не изменилась. Куда копать дальше? З.Ы. Перестало скидывать сессии юзеров в ручную, но я думаю это проблема биллинга.

Вообще делал по этому мануалу http://habrahabr.ru/post/142992/, единственно не понятно, его каждый раз после обновления ядра пересобирать нужно? а то он мне что-то какую-то каку написал на /usr/sbin/pptpd -v accel-pptpd v0.8.5 compiled for pppd-2.4.5, linux-2.6.32-220.2.1.el6.x86_64 а uname -a 2.6.32-279.22.1.el6.x86_64 #1 SMP Wed Feb 6 03:10:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux я так понимаю что он не работает для 279....