BCDC++ 0.403a

Andy_1 · Post by **Andy_1** » 2004-07-07 01:36

i'm using a win 9x based OS and with 0.403a the ntdll "bug" is fixed but now always 100% cpu usage after hashing is finished. would be very nice it can be fixed too in .403b or later

Post by **GargoyleMT** » 2004-07-07 11:23

You'll have to tell us more of what's happening, I haven't seen a 100% cpu usage bug in the latest bcdc.

Andy_1 · Post by **Andy_1** » 2004-07-07 15:06

have installed bcdc++ from .rar and tested it as fresh install with dc++ emu. after adding my share hashing starts and need some time until it was finished. then i've started wintop (from krnltoys) and saw there 98.7% for DCPLUSPLUS. exit bcdc and restarted it, 99.6% without hashing and no hub connected. saw the same in original dc++ 0.402. then i've deleted bcdc++ and got your install (BCDCPlusPlus-0.403a-svn-453b.exe). after installation 97.8 % without any settings/share.

Post by **GargoyleMT** » 2004-07-09 20:58

Andy_1 wrote:saw the same in original dc++ 0.402

If you see 100% cpu utilization in normal, unmodified DC++, then that's important.

How are you judging whether or not hashing is finished?

Andy_1 · Post by **Andy_1** » 2004-07-10 02:46

have installed your BCDC++ 0.403a again and added only 1 gb share in settings. when i hold my mouse over the bottom line a 'protocoll box' pops up and show me which files are already finished with hashing including speed (9.51 KiB/s - 1.34 MiB/s). at bottom line left i can see 'finished hashing ... \' (BCDC in window mode). in fullscreen 'finished hashing ... \<folder>\<filename>'. this operation need 24 minutes on KT400A, XP2400+, 512 MB DDR 3200, Win98. after that without any other settings or connected hub 89.92% cpu usage. exit and new start, same settings, no more hashing, not connected to any hub(s), 86.88% - 91.22%. on top left BCDC 0.403a is shown

clev · Post by **clev** » 2004-07-10 12:23

1GB shared on very old fragmented HDD? :)

Andy_1 · Post by **Andy_1** » 2004-07-10 16:38

1 year old, not fragmented, seagate barracuda iV 80 gb

clev · Post by **clev** » 2004-07-11 04:44

looks like incompatibility with win98? Try standard dc++ to test it :)

cologic · Post by **cologic** » 2004-07-11 06:03

clev:

Andy_1 wrote:saw the same in original dc++ 0.402.

clev · Post by **clev** » 2004-07-11 06:12

OOPS :)

Andy_1 · Post by **Andy_1** » 2004-07-11 11:09

would be nice when dc++ 0.401 has all the features from bcdc++ (dc++ 0.403 is buggy).
but it's possible that all alternatives since 0.4x are dropping win 9x support and aren't based on original dc++ anymore

Todi · Post by **Todi** » 2004-07-11 11:24

Andy_1 wrote:would be nice when dc++ 0.401 has all the features from bcdc++ (dc++ 0.403 is buggy).

I doubt that'll happen anytime soon.. 0.403 works fine for most people.

Andy_1 wrote:but it's possible that all alternatives since 0.4x are dropping win 9x support and aren't based on original dc++ anymore

Not based on original DC++? That's a very strange statement... Of course they are.

Post by **GargoyleMT** » 2004-07-11 20:51

Andy_1 wrote:after that without any other settings or connected hub 89.92% cpu usage. exit and new start, same settings, no more hashing, not connected to any hub(s), 86.88% - 91.22%. on top left BCDC 0.403a is shown

I don't know why CPU utilization is this high, especially since hashing is finished.

There's no way to fix it without knowing what's going on. To do that, a developer has to be able to reproduce that behavior on their computer.

Since you're using WinTop, try a better tool.

Andy_1 wrote:would be nice when dc++ 0.401 has all the features from bcdc++ (dc++ 0.403 is buggy).

Nearly all of the features from BCDC++ are contributed back to DC++. The ones that would be rejected are not. And 0.403 based BCDCs have been stable for me, not as buggy as you suggest.

clev · Post by **clev** » 2004-07-12 05:40

Garg:
[quote=Andy_1]i'm using a win 9x based OS[/quote]

clev · Post by **clev** » 2004-07-12 05:42

SORRY!!!

Post by **GargoyleMT** » 2004-07-12 10:45

Yeah, I was pretty sure SysInternals had both NT and 9x versions of their tools. I think that's what you meant to point out.

As far as compatibility, BCDC 0.307 or so through 0.401 all used a NT specific function for a feature designed for me and a friend. From then on, I made it load the NT specific library only when the function was triggered, which can't be done accidentally.

So, there's no real conspiracy to make (BC)DC++ incompatibile with 9x. On the other hand, it's not tested either, as all of us Developers have real OSes (NT+).

clev · Post by **clev** » 2004-07-13 02:32

again sorry garg, I am blind :(
Did somebody try remote debugging?
I would like to try it, but I borrow Net card from my test machine :-/
(win9x+really real OS-linux) :-P
btw hashing probably looks strange, it uses very much CPU time, even if it is set to IDLE..
probably Thread::Switch will be little helpful somewhere?

Post by **GargoyleMT** » 2004-07-13 11:24

clev wrote:btw hashing probably looks strange, it uses very much CPU time, even if it is set to IDLE.

You can use all of your CPU time with Idle priority... Disk I/O is (can be) CPU intensive, do you know how much is kernel time? There may be a bug, but it doesn't seem obvious that there is one, just from the CPU usage.

Since 0.403, hashing is much slower on my system - and I didn't notice a performance impact with 0.307 or 0.401.

clev wrote:Did somebody try remote debugging?

No, Andy_1 didn't offer.

If so, I need to check my VC.NET CDs to make sure the remote debugging is redistributable, and small enough to send via DC, AIM, or email.

clev · Post by **clev** » 2004-07-13 11:35

I know, but we are talking about windows :), NT or not, some basement is same, if u saw win2k src code somewhere on the inet ;)..
probably hashing lots of small files, makes my Duron crazy ;)

Post by **GargoyleMT** » 2004-07-13 11:47

clev wrote:probably hashing lots of small files, makes my Duron crazy

Well, sure. But are you seeing a noticable performance hit, or are you one of the people who equate 100% cpu utilization to a performance hit?

I ran Distributed.net clients for many years, so 100% CPU usage doesn't bother me.

If it's a real performance hit, how's your disk I/O subsystem - are you running in Ultra DMA mode, with a good cache on your drives, and your filesystem defragmented?

clev · Post by **clev** » 2004-07-13 12:39

yeah, I mean overall system performance is down (system thread/task switching) for example CPU util 60% and GUI is flickering "slowly" drawing and so on..
[wrote=garg]
are you running in Ultra DMA mode, with a good cache on your drives, and your filesystem defragmented
[/wrote]
probably same as your comp, maybe HDD cache is only 2MB........512MB DDR SDRAM....UDMA5

Post by **GargoyleMT** » 2004-07-13 13:42

Well the CPU usage doesn't necessarily mean anything. If you notice it when a bunch of small files are hashing than when large video / cd images are hashing, then it's probably an I/O issue.

clev wrote:probably same as your comp, maybe HDD cache is only 2MB........512MB DDR SDRAM....UDMA5

Probably not. My main computer is a P2.8 with 1gb of ram, a 36gb SATA 10k RPM OS + Application drive, plus four 7200 RPM 200gb 8mb cache WD drives on a 3Ware 7506-4LP RAID controller, in RAID5 mode.

My laptop is a P3/866 with 512mb memory, and a 7200 RPM IBM 60gb drive. I don't notice hashing on this configuration either.

So, are you running the best driver for your IDE controller, and are the master/slave channels set up for Ultra DMA mode in Device Manager? If your I/O subsystem is tuned up as much as you can make it and you still notice hashing, then it's time to dive into the code, particuarly the method of file reading.

Posting what boils down to a complaint about the speed of hashing doesn't improve DC++ or your experience of using it...

clev · Post by **clev** » 2004-07-13 16:00

yeah, try hashing on notebook, it looks like very good test machine - probably it is more near to normal user comp..
Yeah, I think only real lamer running his computer with PIO setup HDDs..
Currently I am running Duron [email protected], cheap UATA100 HDD IBM 80GB 7200rpm 2MB Primary Master with 80pin cable(40p cord) weekly defragmented (divided to 2 NTFS partitions), Asus CDRW 5224 Secondary Master in UDMA mode, 2x256 MB DDR 400MHz..
Duron has small L2 cache, so there should be a problem with switching tasks/threads more visible?

Andy_1 · Post by **Andy_1** » 2004-07-14 03:59

As far as compatibility, BCDC 0.307 or so through 0.401 all used a NT specific function for a feature designed for me and a friend. From then on, I made it load the NT specific library only when the function was triggered, which can't be done accidentally.

BCDC 0.307a was the last one which works fine under Win 9x. only 1 problem: it can't handle new filelist format from DC++ based 0.402 and newer. BCDC 0.401 can't be started under win 9x because of missing NT functions in psapi.dll and ntdll.dll (already discussed)

Since 0.403, hashing is much slower on my system - and I didn't notice a performance impact with 0.307 or 0.401.

Hashing with original DC++ 0.403 is very fast with min 12 MB/s, BCDC++ 0.403a max 1.4 MB/s. Ok, DC++ 0.403 has some display bugs and is set official as unstable but it is the fixed DC++ 0.402 which had the 100% cpu usage bug too. Another thing is that they've dropped old filelist support from clients like 0.3x. Only 0.401 is the universal client with old/new support but there's no complete w9x compatible alternative version

I ran Distributed.net clients for many years, so 100% CPU usage doesn't bother me.

ok, that's your opinion but other ppl want to use the pc for other things too and not DC only. 100% cpu usage before/after hashing isn't funny because BCDC 0.403a blocks the PC

So, there's no real conspiracy to make (BC)DC++ incompatibile with 9x. On the other hand, it's not tested either, as all of us Developers have real OSes (NT+).

lol @real OSes. w9x was before NT. i need no overloaded network/IE/.net OS and the real OS is Unix, not Linux

Post by **GargoyleMT** » 2004-07-14 11:19

Andy_1 wrote:BCDC 0.307a was the last one which works fine under Win 9x. only 1 problem: it can't handle new filelist format from DC++ based 0.402 and newer.

0.307 introduced the XML list, what about it is incompatible with later XML lists?

Andy_1 wrote:DC++ 0.403 has some display bugs and is set official as unstable but it is the fixed DC++ 0.402 which had the 100% cpu usage bug too.

It is no less stable than 0.401, it's just new, and to most users, new is scary.

Andy_1 wrote:Only 0.401 is the universal client with old/new support but there's no complete w9x compatible alternative version

Ugh, 0.403. And if you want to have your 100% cpu usage problem examined, you need to give someone remote access to your machine - it hasn't been noticed by anyone else.

Andy_1 wrote:ok, that's your opinion but other ppl want to use the pc for other things too and not DC only. 100% cpu usage before/after hashing isn't funny because BCDC 0.403a blocks the PC

No, it's not an opinion, it's fact that 100% cpu utilization isn't inherently bad. Distributed.net will only interfere with other threads also running at idle priority. Yes, some people see a performance hit with DC++'s hashing, but that was not the point of what you quoted. (It was to combat people who say that 100% cpu utilization is automatically bad.)

Andy_1 wrote:lol @real OSes. w9x was before NT. i need no overloaded network/IE/.net OS and the real OS is Unix, not Linux

Windows NT 3.1 was released in 1993. Most of the top developers came over from Digital, and so the NT kernel is influenced by VMS. I'm not sure if VMS is UNIX compliant, but anyway...