Oscam cacheex=3 - Част 2
Днес, във версия 7426 е дописвано нещо по cacheex модула, но това няма значение. Тъй като без фикс за memory leak новите версии са неизползваеми за cacheex. Така, че не разбирам, защо някой си губи времето за "козметични" промени, като истинския проблем си остава!?
С това според мен показваш, че там са ти тези кайдове, а не че филтрираш потока до тези изброените ?Originally Posted by turbopower
Използвам същата версия на оскам. Изредил съм 7-8 caids на провайдъри които наистина имат нужда от кеш (без БГ пакети). От самото начало ми правеше впечатление, че за 7-8 пакета твърде много кеш се прекарва. Тава ме накара да пусна линия за каид който не е описан в четеца и акаунта, тогава видях, започна да си взема от кеша въпреки че не би трябвало.
Прикрепил съм статистиките на Сървъра клиент на филтрираният кеш. Щом при мен и при CapNCooK работи, значи причината е при вас. Пак посочвам използвам отделен оскам само за кеша.
cache.txt
еppe1 Прегледай упътването на оскам първо:
Това означава, че оказваш кои ще бъдат на даденият четец - не е за козметика само да си записваш за информация. За cacheex=3 това е особенно важно защото така задаваш (в четеца) кеш от кои caid ще изпращаш. Работи на обратно сравнено с нормалната размяна.define and mapping of CAIDs for reader, default:all CAIDs with mask FFFF
Днес се хавнах да чета за конфигурационните файлове и променливите в тях (отново!). Нещо не ми се вързаха обясненията в тази тема по-напред. В хелповете променливата group при рийдърите пише, че това са групи! Променливата group при юзърите пише, че там се описват групите на рийдърите (до които съответния юзър има достъп до съответния рийдър). От което следва, че многото писане на групи трябва да е в юзърската част. Дали аз съм разбрал погрешно но по-напред в темата се разискваше, че юзърите са с уникални групи а рийдърите трябва да съдържат числата на групите на юзърите които ги ползват. Пренастроих си оскама по единия и по другия начин и все си работи. За мен обаче май по-верен се оказва I-вия вариант, защото навсякъде (при операционните системи и др.) при юзъра се казва какъв ресурс да ползва. Нещото което ме озадачи беше - за да върви кешекса, юзъра който искаме да ползва кеша, трябва да притежава групите както на юзъра с който се закачаме за отдалечения кеш сървър (един юзър да има група на друг юзър) и си го обяснявам така, че явно кеша се взема през потребителски акаунт а мрежовия рийдър към кешекса е само транспорт! Броил съм FOUND-овете от локалната карта и те са точно толкова колкото са изпратени към кешекса, което е доказателство че няма loop!
Работи на обратно спрямо нормалната размяна през readera изпраща, затова са там всичките групи, а през потребителя получава. Това е принципа на работа с 2 изречения, подробностите съм ги написал в темата.
Относно групите в предишният ми пост за това съм се объркал. Значи филтрирате групите в потребителя, или казвате на които ви праща кеша да ги филтрира в неговия reader за вас. Пробвайте сигурен съм че ще работи.
Май 7426 има прблем с пращането на обновяване към друг такъв
Относно фиксването на проблема, ще ви разясня защо не е оправен още, от техническа (професионална), гледна точка. Това е професионално твърдение все пак работя в сферата на софтуера. В момента има defect masking тоест този дефект е маскиран от друг, това е най-трудното за установяване, защото друг дефект е причината, които няма нищо общо с въпросната фунционалност. По тази причина Георги като опитен програмист е започнал преработването (refactoring) на оскама което хем ще промени мацаното между билдовете хем ще оправи подобни "маскирани" проблеми. Все пак този оскам е unstable тоест не е и alpha версия, така че до като стигне финална стабилна версия трябва да е оправено. Аз лично не харесвам като започнат да пишат тук, хора които нямат опит в писане на софтуер, да изказват крайни мнения, които в по голямата си част са остри коментари без никаква техническа стойност и без нужните доводи за това.
Аз участвам в такъв форум защото се занимавам професионално със софтуер и хардуер, така че нормално е да заставам против неправилно представени постове, без никакви уместни доказателства в тях. Като се опитвам да представя нещата спрямо познанията, световно приетите практики за изграждане и развиване на софтуер може да не са правилни според вас, но това са стандартите в момента, които са се доказали в практиката.
Ето едно интересно четиво, което се появи в streamboard-а, отнасящо за филтрите по caid при cacheex mode3:
Filter the cacheex 3 to improve bandwith, memory and CPU
Posting Permissions
