So, it's not just me, ....

For the generic offtopic chit-chat
Post Reply
ciaobaby

So, it's not just me, ....

Post by ciaobaby »

... ... that thinks 'Linux' mind-set developers act like a band of pirates with little or no thinking ahead ...


with reference to this post and this article

(the post came before I read the article)


Look at what has been achieved and imagine what COULD be done with some real co-operation. ... ... Micro$oft and App£e wouldn't know what hit them.
sledgehammer_999
Administrator
Administrator
Posts: 2443
Joined: Sun Jan 23, 2011 1:17 pm

Re: So, it's not just me, ....

Post by sledgehammer_999 »

It isn't linux mind-set. It is "open source done as a side project/hobby project/non-fulltime project". In other words, when you spend only your free time on something you cannot be overly organized, especially on supporting users...
ciaobaby

Re: So, it's not just me, ....

Post by ciaobaby »

You can't be organized in the division of labour certainly, but the approach to the testing and communication regarding development can be. With a closed group of developers it is easy certainly, but with all the methods of communication that exist now it's not that difficult for a distributed group to be aware of what anyone else is doing so there isn't three people 'fixing' the same set of files and code, each doing their 'own thing' that may or may not be compatible when it is time to 'bolt it all together'.

There is finally a bit of a coding guideline.
There is no defined or common method for naming objects and variables, some use CamelCase, others use or have used all lowercase with underscores, while there are some using CamelCase_and_Underscores.

You have complained and deleted the posts where I am/was trying to get the people who ARE experiencing crashing with large cache sizes and high speeds  to reduce their cache and see if they STILL get crashes. You can only pin down a code issue or use case problem by narrowing down and isolating the parameters that cause the crash.
If it still bombs outs with a smaller cache then there IS  some kind of resource leak and the project is  one step nearer to the cause and finding a fix. But without having results and test data from a range of users who are willing try different solutions / workarounds rather than just arguing the toss and willy-waving over who's problem is the worse, you are just pissing into the wind (to use a couple of 'colourful' metaphors).

Personally I don't give a crap whether running on 64bit with a 4GB cache blows up to 5 GB because of Windows stupid cache handling or 32 bit crashes more often with 1800 MB cache, THAT goes without saying. What you need to to know if the cache also 'blows up' when starting from 250KB as well so priorities can be set for tracking down the REAL bugs, rather the non-issues that attract a lot of noise rather than any clear signal.
sledgehammer_999
Administrator
Administrator
Posts: 2443
Joined: Sun Jan 23, 2011 1:17 pm

Re: So, it's not just me, ....

Post by sledgehammer_999 »

I don't think I deleted posts of yours relating to cache...
I didn't tell him to test with 256KB or 150MB to test if RAM blows up, because at those limits you can discern if the RAM usage belongs to the cache or to the rest of the program...
ciaobaby

Re: So, it's not just me, ....

Post by ciaobaby »

But it is information that IS needed in order to make an informed judgement, if you do not have such information it is just guessing what is happening on somebody else's system.
At high cache sizes, a crash IS pretty much inevitable, almost guaranteed to occur, BUT, does it also happen ON THE SAME machines without Gibibyte cache sizes??
You don't have that data and you will not be able set up the same conditions to ascertain the results, so you have to get others to set and test different conditions, qBT is never going to be run solely in an ideal environment, with perfect settings so you need to know the "safe working limits". Currently it is patently obvious that a maximum of 1800 is WAY over the safe point, but what is a 'safe' maximum that WILL prevent users from setting values that they think or have 'read somewhere' are useful but are actually detrimental to performance??
The only people who can help determine that, ARE the ones that are having the problems and are willing to help themselves and the overall project at the same time.

Someone commented that findings were useless because my "config was low", now THAT shows a lack of understanding of BitTorrent in general, my configuration is ideal for how I run my systems. There is no "one size fits all", so for whomever that was, ... ... it's not the numbers that matter;

It is the relationship of the numbers, the ratio of connections to cache (or memory use) is very likely to be similar across configurations and use cases. The numbers may vary widely but you will only find the 'best fit' for your system by trying many different 'tweaks'.

because at those limits you can discern if the RAM usage belongs to the cache or to the rest of the program...
Should that be "cannot discern"? If so, then sure, just as you can't say categorically if it IS the huge reserved cache size  or the application image that causes the crash, it takes testing at many combinations of cache size, as the only easily adjustable user variable to separate cause from effect.
ciaobaby

Re: So, it's not just me, ....

Post by ciaobaby »

By the way;

this and this is the kind of thing I mean about being organised and co-operative, just talk to each other about your ideas while you are actually working on them or before starting on a 'hack', somebody else may be able to help with additional suggestions.
Post Reply