Покажи Публикации - gat3way
* Виж публикациите на потр. | Виж темите на потр. | Виж прикачените файлове на потр
Страници: 1 ... 406 407 [408] 409
6106  Хумор, сатира и забава / Хумор / Microsoft news -: Sep 15, 2006, 15:28
Агенте, драги, умолявам те да не вземаш нещата толкова присърце '<img'>

С Доктора се познаваме, въпреки че не одобрявам неговите настроения по въпроса (а и разбираш ли, вярвам че до голяма степен го прави напук). В добавка предполагам знаеш с какво се занимава на работа, Астериск не знам да са правили уиндоуски версии, предполагам знаеш какво правят в Секюракс и такам...моля те да не ме заплашваш с него все пак, мене ме е страх от него, но по други параграфи, няма общо с майкрософт '<img'>

Жълта преса не чета. Всъщност никаква преса не чета. За Кривото от време на време ми се ще да се смъкна...обаче винаги се оказва, че магазина за бира ми е на 2 крачки, а Кривото на 5-6 километра...и мързелът надделява '<img'>

Таа няма нужда наистина да вземаш толкова маргинална позиция..може да приказваме, да адвокатстваме на каквото и да било, да къртим мивки, рулираме и т.н. и да даваме етикети, но смисъл особено няма. Недейте взема нещата толкова присърце '<img'>

...Пък и за "експертите" (в кавички) не можеш да ме убедиш че ги няма..мога да ти разправям колкото искаш истории за такива, от първа ръка, от втора ръка, както предполагам и не само аз мога да разказвам '<img'>


// оффтопик: прати поздрави на Франки от мен (никнейма) като го видиш...отдавна не съм го виждал/чувал '<img'>



6107  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Dns въпрос -: Sep 15, 2006, 15:09
Всъщност NS записите почти не касаят браузъра...той си прави gethostbyname(), което всъщност прави една заявка за А записа до dns сървърите сложени в resolv.conf...NS записа е нещо което касае най-вече тези сървъри: къде да се обърнат, за да изискат исканите от клиента(браузъра) А записи.

Ако няма нищо кеширано, тогава се обръщат или към forwarder-a (ако има) или директно към "root" сървърите, където съответно се пазят авторитивните NS записи (тези дето се дават като регистрираш домейна). В последствие се обръща към тях за да им иска нужния А запис.

Що се отнася до това дали заявките се балансират...мисля че ги кара едно след друго, т.е ако първия не върне резултат до определено време се обръща към следващия. Но не съм 100% убеден за това, предполагам иначе го пише из разни rfc-та..
6108  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Dns въпрос -: Sep 15, 2006, 12:21
Не съм казал че трябва да има няколко апача или че не могат да слухтят на няколко интерфейса, това се отнасяше за bind и за това че трябва да се връща различна информация в зависимост от това към кой интерфейс идва DNS запитването. Малко тъпо би било да ти дойде запитване за А записа на домейна и да му върнеш айпи адреса на другия интерфейс, който  в момента е паднал....и така.

Но всъщност, не се замислих че има views в bind, откъдето може и да се реши проблема без пускането на 2 копия на демона с различни зонови файлове. Обаче не съм много запознат с тези нововъведения де, който им разбира повече да си каже..
6109  Хумор, сатира и забава / Живота, вселената и някакви други глупости / Помогнете да спасим Витоша -: Sep 15, 2006, 10:15
Специално заради v-sag и tarkan съм там съботата...иначе колко ще спася Витоша е отделен въпрос..
6110  Linux секция за начинаещи / Настройка на програми / въпрос за ограничаване на udp tcp i acmp конекции -: Sep 15, 2006, 02:21
Единственият udp трафик дето би трябвало да се пуска приоритетно е DNS трафика според мен. И въпреки всичко приказките около злоупотребите с рекурсивни сървъри и amplification атаките свързани с тях разубеждават...

Но пък знам ли ги какви са им практиките из провайдърите, специално що се отнася до voip трафика съм чувал че при големите провайдъри си имало разни други, главно икономически съображения за QoS policies..там покрай дебата за network neutrality законите в Щатите нали имаше доста караници, както и едни флаш филмчета, разбира се с магистрали, коли и задръствания (странно защо нямаше с водопроводи, ХАХА)..

Обаче никога не съм работил в ISP, а и не обичам особено да се размотавам с  хора, занимаващи се с линукс или networking, освен колегите ми на работа де..така че нямам мнение по въпроса, просто нямам поглед върху това какво се прави из провайдърите...
6111  Linux секция за начинаещи / Настройка на програми / въпрос за ограничаване на udp tcp i acmp конекции -: Sep 14, 2006, 22:14
Значи ако условно наречем UDP трафика от даден хост/порт към някой порт на клиентска машина - *конекция*

*Не можеш да ограничиш броя на *конекциите*, за съжаление

*Можеш да ограничиш скоростта на трафика от *конекции* установени от твои клиенти към външни хостове (voip трафика носещ гласа на 8твоите клиенти)

* Можеш да ограничиш скоростта с която минава voip трафика  от рутера ти до твоите клиенти, но не и скоростта на същия трафик идващ от модема към рутера ти . (т.е voip трафика представляващ гласа на събеседника на клиентите ти, в пътя и от твоят рутер до конкретния твой клиент)

* С ingress шейпинг правиш горе долу същото, малко по-грубо, само че там ограничаваш скоростта малко преди това,т.е, скоростта с която целият трафик минава между момента в който влиза от входящия интерфейс до момента в който  бъде минат през рутинг и нат алгоритмите , след което важат ограниченията, които налагаш от горния параграф (бахмалоумното обяснение, съжалявам, но ми е малко трудно да го обясня без да начертая глупостите)

Така стоят нещата, грубо казано не можеш да контролираш това което влиза в мрежата ти от интернет. Можеш единствено да ограничаваш *надеждно* изходящият трафик. Понеже няма как да ти знам изискванията и ип адресите на клиентите въобще няма как да ти приготвя скрипта дето ще ти свърши работа. И все пак, прочети linux advanced routing & traffic control, http://www.lartc.org

Защо можеш да ограничаваш по-ефективно TCP трафик отколкото UDP такъв: все пак при TCP за всеки изпратен пакет се изискват потвърждения че е получен под формата на "потвърждаващ" TCP пакет. Колкото по-бавно се връщат тези потвърждения, толкова по-бавно ще бъде изпратен следващият пакет информация...докато при UDP никой не му дреме потвърждава ли се всеки изпратен пакет...и така



6112  Linux секция за начинаещи / Настройка на програми / въпрос за ограничаване на udp tcp i acmp конекции -: Sep 14, 2006, 17:00
Цитат

да но Skype ползва udp връзки а всички в мрежата ползват skype и се floodи модема с повече от 60 конекции едвам отварям страници без значение от скороста на теглене в момента или че конекциите са udp ... няма да споменавам тракери защото ако някой пусне тракер си отварям 1 час пощата ... а за icmp вчера единия от мрежата имаше някакъв вирус който ъплоудваше с макс скорост и не можех да го спра ...


Сега не искам да се заяждам, но няма такова нещо като "udp връзки". Има протоколи които надграждат UDP добавяйки му някаква степен на TCP-подобна функционалност (такъв е RUDP), които ужким са измисляни за стрийминг приложения с ужким  контролирано от потребителя качество върху бавни връзки алабала...но не знам да са влезнали в масова употреба. RDP използван за quicktime стриймване главно не е базиран върху UDP а върху IP.

Много  надълго ще стане ако тръгна да обяснявам каква е разликата между TCP и UDP, въпреки всичко това би трябвало да се знае от всеки човек, който претендира че се занимава с мрежови глупости.

Да, скайп и битторънт използват и двата протокола. UDP поради характера си има една много досадна характеристика - тъй като не се установява връзка, не можеш да върнеш един пакет с RST флаг и да видиш сметката на целия по-нататъшен трафик (това което прави netfilter кода в ядрото  като му набиеш лимит на TCP конекциите и ги превишиш).

От друга страна, UDP трафика си тече и отсрещната машина принципно няма идея дали получателя го получава, колко от него получава и с каква скорост смогва да обработи пакетите - неща които в TCP са решени чрез механизми като windows и sequence numbers. Поради тази причина  съвсем лесно се стига до твоят случай, когато по-голям udp трафик запълва цялата линия. От друга страна няма механизъм по който ти да кажеш на изпращащите хостове "спри, не искам да ми пращаш повече" или "намали скоростта на изпращане, не мога да ти смогна!"

Откъдето идва един неприятен момент - ingres шейпинг-а помага доста, стига трафика да е tcp, но при udp трафик и това не е гаранция. И все пак, шейпвайки го доволно добре постигаш един "психологически" момент (хаха) - когато един твой клиент види че разговорът му върви насечено, той ще спре да се опитва да говори и ще затвори. Това в кръга на шегата де '<img'>

Битторънт протоколът съвсем спокойно може да си работи единствено по TCP, затова най-добре блокирай всичкия входящ/изходящ udp трафик на неговите портове (6880-7000 / udp). Както вече споменах, TCP много по-лесно се подава на контролиране.

Що се отнася до ICMP, с него проблемът е сходен. Ако някой от клиентите ти прихване лош вирус и тръгне да задръства линията с icmp пакети, лесно ще го орежеш с HTB/CBQ. Ако някой отвън реши да те задръсти обаче, дори ingres шейпинг-а няма да ти помогне особено - пакетите ще пристигат при теб, дали ще им обръщаш внимание или не няма значение тъй като няма механизъм по който да кажеш на изпращащият хост да спре или поне да намали скоростта на изпращане.



6113  Linux секция за начинаещи / Настройка на програми / въпрос за ограничаване на udp tcp i acmp конекции -: Sep 14, 2006, 16:08
Няма такова нещо като udp или icmp конекции, тези протоколи сами по себе си не предвиждат установяването на връзка.

Твърде вероятно шейпването на трафик ще оправи нещата, но ще трябва да сложиш и правила за INGRES шейпинг.
6114  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Vpn рутиране -: Sep 14, 2006, 15:18
Пействай ifconfig/route -n от сървъра.
6115  Хумор, сатира и забава / Хумор / Microsoft news -: Sep 14, 2006, 14:27
Тва за мене ли беше? '<img'>

Всъщност за мен лично най-хубавото което съм виждал от уиндоус е Exchange server-a, за моите потребности свързани с електронни таблици никога не ми се е случвало да ми се налага да правя нещо, което Оо да не може да свърши..а и като се замисля как добре се интегрира с домейн контролери...верно има openexchange но последното не струва...
6116  Хумор, сатира и забава / Хумор / Microsoft news -: Sep 14, 2006, 14:12
И все пак май уиндоуските "експерти" са по-зле, фанатиците поне порастват някой ден, докато другите обикновено си остават тъпи завинаги..

Субективни наблюдения де..
6117  Хумор, сатира и забава / Хумор / Microsoft news -: Sep 14, 2006, 13:47
Чудя се кое е по-зле: да си тъп ОСС фанатик, който дори не познава софтуера, за който адвокатства. Или да си от ония малоумни "експерти", които доминират средите на майкрософтските потребители.

Ех..
6118  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Smp помощ -: Sep 14, 2006, 11:43
Трябва ти X86_IO_APIC подръжка в ядрото, виж дали не буут-ваш с noapic също така, защото това не е ли изпълнено, дори да си го компилирал с irq balancing, няма да сработи.

Сега да обясня вижданията си по въпроса '<img'> Има няколко варианта за "балансиране" на прекъсванията:

1) Всички прекъсвания се изпълняват на първия процесор (цпу0) - както е в случая. Всъщност, това не е толкова лошо, из мейлинг листите на кърнъл девелоперите съм виждал статии които адвокатстват за това решение. Чел съм че в определени случаи това е по-добрият вариант (при интелски процесори с много кеш).

2) Набиваш през /proc твърдо кое прекъсване на кой процесор се изпълнява. На мен лично този вариант най-много ми допада, особено ако става въпрос примерно за рутер с 2 интерфейса през който минава повечко трафик...или пък ИДЕ райд масив

3) kernel IRQ balancing - в ядрата 2.6, дам. Не мисля че това е кой знае колко добра идея, особено що се отнася до един процесор с няколко ядра, според мен единствено ще донесе повече overhead.

4) userspace-ска джаджа (като irqbalance) която прави същото - според мен е абсолютна глупост при 2.6 ядра.

---------

Що се отнася до NMIs, при х86_64 по дефолт ядрата се компилират с NMI watchdog. Всяка секунда таймера генерира NMI. В ядрото има една проверка ако 5 секунди броят на NMI прекъсванията върху един процесор не се увеличават, тогава определено има проблем, съответно излиза онзи лош екран Oops...като се издъмпва съдържанието на стека и регистрите за да може някой брадат мустакат кърнъл девелопер да си поблъска главата защо се случва това (все пак кода за х86_64 е доста по-"млад" от този за i386...)

Ако разгледате файла nmi.c вътре си го пише в един коментар...
Цитат

 /*
 * the best way to detect whether a CPU has a 'hard lockup' problem
 * is to check it's local APIC timer IRQ counts. If they are not
 * changing then that CPU has some problem.
 *
 * as these watchdog NMI IRQs are generated on every CPU, we only
 * have to check the current processor.
 *
 * since NMIs don't listen to _any_ locks, we have to be extremely
 * careful not to rely on unsafe variables. The printk might lock
 * up though, so we have to break up any console locks first ...
 * [when there will be more tty-related locks, break them up
 *  here too!]
 */



Това предполагам генерира известно забавяне, тъй като всяка секунда се обработва това прекъсване, но вероятно е пренебрежително малко.
6119  Linux секция за начинаещи / Настройка на програми / Osr на картинка ? -: Sep 12, 2006, 15:56
Значи доколкото съм запознат с тези алгоритми, при положение че имаш достатъчно много линийки, петънца и точки, векторизацията ще доведе до някаква грозна ситуация. Оттам нататък е достатъчно част от числото да излиза извън картинката (но така че гледайки го все пак да го разпознаеш - примерно една цифра "6" на която лявата 1/4 е извън картинката) и разпознаването пропада със сигурност. По мои скромни наблюдения почти винаги нарочно част от числото/думата излиза извън картинката, съвсем нарочно е това да знаеш '<img'>

50% успевяемост ако изкараш ехеееее обезсмисляш проверката '<img'>

Трябваше да пробваш да подадеш няколко такива картинки на finereader-a преди това, защо не пробваш да видим от колко картинки ще уцелиш числото поне веднъж...
6120  Linux секция за начинаещи / Настройка на програми / Osr на картинка ? -: Sep 12, 2006, 15:20
Уааа '<img'>

Пробвай да разпознаеш "цифричките" от сайта на мтел с какъвто и да е OCR - надали ще имаш повече от 10% успех, че и тва ми се вижда много.

Имайки предвид от една страна тази успевяемост, от друга страна процесорното време и честотната лента, която се троши за задачата, мога да ти предложа по-успешен подход: bruteforce!!!  

Разбираш ли, шанса да успееш да се лог-неш така е много по-голям!!! Шанса да направиш хахорската поразия на живота си тоже '<img'>

Другият вариант е да подобриш съществено алгоритъма за разпознаване. Апропо, след като го подобриш, напиши и един скрипт дето пуска 200000 анонимни мнения в slashdot, тогава целият свят ще те признае за зъл хахор, хак дъ планет дет се вика...
Страници: 1 ... 406 407 [408] 409