|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 30 Nov 2001 21:42:43
To : Svyatoslav Abramenkov
Subject : Re: Линк с виндами.
--------------------------------------------------------------------------------
On Fri, 30 Nov 2001 12:03:04 +0300,
Svyatoslav Abramenkov <Svyatoslav.Abramenkov@p100.f8088.n464.z2.fidonet.org>
wrote:
>Hello, Ilya!
>
>At 29 Nov 01 19:16:13, Ilya Anfimov wrote to Svyatoslav Abramenkov:
>
[skipped]
> IA> А теперь загляни в plip.c и приколись -- нет там такого
> IA> кода. Как класса нет. В начале файла -- какая-то отмазка, типа
> IA> когда-то был да выкинули. Почему-то.
> Отэто да... Даже отмазки нетути, с 2.0.34 и аж до 2.2.19 |-(... Правда,
>из кода все равно не ясно, почему так медленно. Уж 40-50 кб/с он все же как-то
>мог бы обеспечивать. Впрочем, вполне понятно, что связь симплексная и все
>задержки формируются драйвером, в отличии от аппаратного UART, и здесь, похоже,
>и есть основной минус.
Возможно, что поэтому. Вообще, timeoutы дело несколько меняли,
но несильно и ненадолго :-) (Все закруглялось и висло если
перестараться).
А возможно, что также из-за отсутствия interrupt-driven input
и использование polling. Таким образом, передача данных
происходила только тогда, когда управление было
у это кода.
Предположим, что на обоих концах ему выделяется по 30% cputime
чистыми (замечу, что то, что меряет top -- это все-таки попугаи,
к тому же здесь интересует именно время, которое можно потратить
внутри plip_send и plip_receive, а не на перераспределение в
scheduler, разбор ethernet кадра и другие крайне неотложные дела.
Тогда plip_receive будет заниматься взаимодействием с plip_send
примерно 9% времени, и скорость упадет примерно в 10 раз. В
отличие от user-space программ с теми же проблемами на socketах,
никакого логичного поведения scheduler и поднятия приоритета
именно в те моменты, когда долгожданные данные поступают, не
приходится. Так как в данном случае он никак не сможет понять,
что этот _receive ждет у моря погоды, а не засасывает
столь желанные байтики.
ОТМАЗКА: Вышесказанное не является в каком-либо смысле рассчетом,
это просто иллюстрация моей мысли по поводу источника торможения.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
