weird problem with upd3 - dos.library?

A forum for general AmigaOS 4.x support questions that are not platform-specific
User avatar
MichaelMerkel
Beta Tester
Beta Tester
Posts: 350
Joined: Mon Dec 20, 2010 2:08 pm
Location: Germany
Contact:

Re: weird problem with upd3 - dos.library?

Post by MichaelMerkel »

corto wrote:Michael : I think about something that you could try. Maybe you could run my profiler Hieronymus, as the delay is more than 5 seconds. With a debug version of YAM, that could point on the function in which much time is spent. I would be interested in the results.
Remember that at the moment, Hieronymus only works on AmigaOne, unfortunately.
i now tried hieronymus. i booted from a clean os4.1upd3 partition. hieronymus run for 15 seconds.
first test is using the upd3 dos.library. second is using dos.library from upd2. i booted and started "alarmist" time for the popup to display:
dos.upd3: ~9 seconds
dos.upd2: ~3 seconds

and here is the hieronymus logs:
dos.upd3: :

Code: Select all

Acquiring data, please wait ...

Hieronymus got 900 samples in 15 seconds.

Report of cache misses :

L1 inst cache misses : 5255
L2 inst cache misses : 0
L1 data cache misses : -1077246339
L2 data cache misses : 0

Detailed results :

count = 0876, percent = 97, name = Kickstart/kernel
  Offset = 0x0000da2c, Count = 0853, Function = HAL_TaskPostTerm
  Offset = 0x00030ee0, Count = 0001, Function = _impl_KMemCacheDestroy
  Offset = 0x0001e304, Count = 0010, Function = <NOT FOUND>
  Offset = 0x0003b480, Count = 0001, Function = btpool_get_large
  Offset = 0x0001a4d4, Count = 0001, Function = _impl_AllocVecPooled
  Offset = 0x0001c68c, Count = 0002, Function = _impl_Enable
  Offset = 0x0003b75c, Count = 0001, Function = btpool_alloc
  Offset = 0x00007738, Count = 0001, Function = _impl_UserState
  Offset = 0x00007868, Count = 0002, Function = _impl_Supervisor
  Offset = 0x000096ac, Count = 0001, Function = HAL_GetDBATPair
  Offset = 0x0000a1c0, Count = 0001, Function = HAL_GetPhysicalAddress
  Offset = 0x0001c8bc, Count = 0001, Function = _impl_Permit
  Offset = 0x0000a34c, Count = 0001, Function = HAL_GetPageAttrs
count = 0003, percent = 00, name = Kickstart/intuition.library.kmod
  Offset = 0x00030cc0, Count = 0003, Function = <NOT FOUND>
count = 0002, percent = 00, name = Kickstart/timer.device.kmod
  Offset = 0x00002018, Count = 0002, Function = <NOT FOUND>
count = 0002, percent = 00, name = Kickstart/ramlib.kmod
  Offset = 0x00001a24, Count = 0001, Function = Find_Seg_RomTag
  Offset = 0x00008544, Count = 0001, Function = <NOT FOUND>
count = 0005, percent = 00, name = Kickstart/dos.library.kmod
  Offset = 0x00032000, Count = 0001, Function = raw_FGetC
  Offset = 0x0000e06c, Count = 0001, Function = allocExNode
  Offset = 0x0002be1c, Count = 0001, Function = J_StrToLong
  Offset = 0x00002390, Count = 0001, Function = J_AssignPath
  Offset = 0x0000dbd8, Count = 0001, Function = J_ExamineFH
count = 0012, percent = 01, name = LIBS:ft2.library
  Offset = 0x0001acdc, Count = 0012, Function = <NOT FOUND>

Summarized results :

Percent | Program
   97   | SYS:Kickstart/kernel
    0   | SYS:Kickstart/intuition.library.kmod
    0   | SYS:Kickstart/timer.device.kmod
    0   | SYS:Kickstart/ramlib.kmod
    0   | SYS:Kickstart/dos.library.kmod
    1   | LIBS:ft2.library
dos.upd2: :

Code: Select all

Acquiring data, please wait ...

Hieronymus got 900 samples in 15 seconds.

Report of cache misses :

L1 inst cache misses : 2587
L2 inst cache misses : 0
L1 data cache misses : -1047501221
L2 data cache misses : 0

Detailed results :

count = 0874, percent = 97, name = Kickstart/kernel
  Offset = 0x0000da2c, Count = 0858, Function = HAL_TaskPostTerm
  Offset = 0x0000b080, Count = 0001, Function = _impl_AddIntServer
  Offset = 0x0003b608, Count = 0002, Function = btpool_get_small
  Offset = 0x00012ca0, Count = 0008, Function = <NOT FOUND>
  Offset = 0x00007738, Count = 0001, Function = _impl_UserState
  Offset = 0x0001c8bc, Count = 0001, Function = _impl_Permit
  Offset = 0x000480d4, Count = 0001, Function = _util_NextTagItem
  Offset = 0x0000a31c, Count = 0002, Function = HAL_GetPageAttrs
count = 0002, percent = 00, name = Kickstart/ATIRadeon.chip
  Offset = 0x0000b080, Count = 0002, Function = <NOT FOUND>
count = 0005, percent = 00, name = Kickstart/timer.device.kmod
  Offset = 0x00002018, Count = 0005, Function = <NOT FOUND>
count = 0007, percent = 00, name = LIBS:ft2.library
  Offset = 0x00019044, Count = 0007, Function = <NOT FOUND>
count = 0002, percent = 00, name = Kickstart/newlib.library.kmod
  Offset = 0x00007c20, Count = 0002, Function = <NOT FOUND>
count = 0002, percent = 00, name = CLASSES:datatypes/png.datatype
  Offset = 0x0000bb50, Count = 0002, Function = <NOT FOUND>
count = 0002, percent = 00, name = Kickstart/rtg.library
  Offset = 0x00052790, Count = 0002, Function = <NOT FOUND>
count = 0006, percent = 00, name = Kickstart/intuition.library.kmod
  Offset = 0x00034bf8, Count = 0006, Function = <NOT FOUND>

Summarized results :

Percent | Program
   97   | SYS:Kickstart/kernel
    0   | SYS:Kickstart/ATIRadeon.chip
    0   | SYS:Kickstart/timer.device.kmod
    0   | LIBS:ft2.library
    0   | SYS:Kickstart/newlib.library.kmod
    0   | CLASSES:datatypes/png.datatype
    0   | SYS:Kickstart/rtg.library
    0   | SYS:Kickstart/intuition.library.kmod
anything wchich can be seen here? i don't think so :-(

regards...
michael
Michael Merkel :lol:
(Member of Amiga Freunde Pfalz)
xenic
Posts: 1183
Joined: Sun Jun 19, 2011 12:06 am

Re: weird problem with upd3 - dos.library?

Post by xenic »

Since the programs you tested are probably loading a lot of small files, I decided to run a copy test using AISS TBImages directory. That directory is only 7+MB in size but contains over 5000 tiny image files and a PDF.
Results with Update3 dos library:
copy TBImages from SFS2 partition to Ram: = 31 seconds
copy TBImages from FFS partition to Ram: = 1 minute 38 seconds
Results with Update2 dos library:
copy TBImages from SFS2 partition to Ram: = 26 seconds
copy TBImages from FFS partition to Ram: = 1 minute 41 seconds

The difference seems to depend on the filesystem and seems almost insignificant to me.
What's really significant is how long it took to copy TBImages from an SFS2 partition to an FFS partition in order to run the above test; an unbelievable 7 minutes and 35 seconds! No wonder few people use FFS anymore :-)
AmigaOne X1000 with 2GB memory - OS4.1 FE
corto
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 40
Joined: Sun Jun 19, 2011 8:53 am

Re: weird problem with upd3 - dos.library?

Post by corto »

Thanks Michael. That's always nice to have a feedback on this tool !
Unfortunately, in your case, you're right, there is nothing to really helpful except that that shows the system was in IDLE state. There is no actvity in YAM or dos.library.
chris
Posts: 555
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: weird problem with upd3 - dos.library?

Post by chris »

xenic wrote:Since the programs you tested are probably loading a lot of small files, I decided to run a copy test using AISS TBImages directory. That directory is only 7+MB in size but contains over 5000 tiny image files and a PDF.
Results with Update3 dos library:
copy TBImages from SFS2 partition to Ram: = 31 seconds
copy TBImages from FFS partition to Ram: = 1 minute 38 seconds
Results with Update2 dos library:
copy TBImages from SFS2 partition to Ram: = 26 seconds
copy TBImages from FFS partition to Ram: = 1 minute 41 seconds

The difference seems to depend on the filesystem and seems almost insignificant to me.
What's really significant is how long it took to copy TBImages from an SFS2 partition to an FFS partition in order to run the above test; an unbelievable 7 minutes and 35 seconds! No wonder few people use FFS anymore :-)
I've just tried the same test (using WB) from an SFS partition to RAM, and it took nearly 3 minutes!
There is clearly something wrong in dos.library or the device drivers. I usually use JXFS (that's where YAM is) but TBImages happens to be on my boot partition, so has to be SFS.
xenic
Posts: 1183
Joined: Sun Jun 19, 2011 12:06 am

Re: weird problem with upd3 - dos.library?

Post by xenic »

chris wrote: I've just tried the same test (using WB) from an SFS partition to RAM, and it took nearly 3 minutes!
There is clearly something wrong in dos.library or the device drivers. I usually use JXFS (that's where YAM is) but TBImages happens to be on my boot partition, so has to be SFS.
I didn't mention that I did my copy with Dopus4. Since I was just looking for a relative comparison between Update2 dos and Update3 dos I didn't think the copy method was relevant. For your benefit I did a WorkBench drag'n drop copy of TBImages (Update3 dos) from an SFS partition to ram: and the time was 24 seconds. The same copy using the AmigaDOS "copy TBImages TO ram:TBImages ALL QUIET" only took 21 seconds. Is your TBImages about the same size as mine?? I'm using a SAM Flex 800MHz but I don't think our times should be that different. Maybe you have something like a notification set up on ram: or a file in ram: that is slowing things down.

P.S. I noticed an apparent bug in WorkBench copies. If I drag a directory that has no icon (using the DefIcons ghosted icon) WorkBench creates a real drawer (with no name) in the destination drawer and then displays a ghosted icon with the directory name when the copy is complete. I end up with 2 icons from the copy; a real one with no name and a ghosted one with the directory name. The real icon disappears when I close the window and reopen it. I'm off to see if anyone else has reported the bug and add a topic if not.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
cha05e90
Posts: 90
Joined: Fri Jun 17, 2011 10:15 pm
Location: Germany
Contact:

Re: weird problem with upd3 - dos.library?

Post by cha05e90 »

xenic wrote: P.S. I noticed an apparent bug in WorkBench copies. If I drag a directory that has no icon (using the DefIcons ghosted icon) WorkBench creates a real drawer (with no name) in the destination drawer and then displays a ghosted icon with the directory name when the copy is complete. I end up with 2 icons from the copy; a real one with no name and a ghosted one with the directory name. The real icon disappears when I close the window and reopen it. I'm off to see if anyone else has reported the bug and add a topic if not.
I can confirm this behaviour.
X1000|II/G4|440ep|2000/060|2000/040|1000
xenic
Posts: 1183
Joined: Sun Jun 19, 2011 12:06 am

Re: weird problem with upd3 - dos.library?

Post by xenic »

cha05e90 wrote: I can confirm this behaviour.
Somebody already report it but thought it only happens if the source drawer is in text mode. I added a comment that it also happens if the source is in icon mode with show all files set.
AmigaOne X1000 with 2GB memory - OS4.1 FE
chris
Posts: 555
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: weird problem with upd3 - dos.library?

Post by chris »

xenic wrote:
chris wrote: I've just tried the same test (using WB) from an SFS partition to RAM, and it took nearly 3 minutes!
There is clearly something wrong in dos.library or the device drivers. I usually use JXFS (that's where YAM is) but TBImages happens to be on my boot partition, so has to be SFS.
I didn't mention that I did my copy with Dopus4. Since I was just looking for a relative comparison between Update2 dos and Update3 dos I didn't think the copy method was relevant. For your benefit I did a WorkBench drag'n drop copy of TBImages (Update3 dos) from an SFS partition to ram: and the time was 24 seconds. The same copy using the AmigaDOS "copy TBImages TO ram:TBImages ALL QUIET" only took 21 seconds. Is your TBImages about the same size as mine?? I'm using a SAM Flex 800MHz but I don't think our times should be that different. Maybe you have something like a notification set up on ram: or a file in ram: that is slowing things down.
My TBimages is "5,246,848 bytes in 5,257 files"
Using a 600MHz Sam440EP here (ie. non-Flex)
xenic
Posts: 1183
Joined: Sun Jun 19, 2011 12:06 am

Re: weird problem with upd3 - dos.library?

Post by xenic »

chris wrote: My TBimages is "5,246,848 bytes in 5,257 files"
Using a 600MHz Sam440EP here (ie. non-Flex)
I removed the PDF from my TBImages directory which makes it the same size as yours. I retested WorkBench copy from SFS partition to RAM :and got 22 seconds without the PDF file. Based on CPU speed, one would thing that a copy would only take 30% longer on your system (10-15 secs) and not 5 times longer.

EDIT: I switched my SAM Flex to 667 MHz to see if it is more stable and while I was at it I repeated the above speed test for a TBImages copy and the result was 33 seconds as I would expect.
AmigaOne X1000 with 2GB memory - OS4.1 FE
chris
Posts: 555
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: weird problem with upd3 - dos.library?

Post by chris »

xenic wrote:
chris wrote: My TBimages is "5,246,848 bytes in 5,257 files"
Using a 600MHz Sam440EP here (ie. non-Flex)
I removed the PDF from my TBImages directory which makes it the same size as yours. I retested WorkBench copy from SFS partition to RAM :and got 22 seconds without the PDF file. Based on CPU speed, one would thing that a copy would only take 30% longer on your system (10-15 secs) and not 5 times longer.

EDIT: I switched my SAM Flex to 667 MHz to see if it is more stable and while I was at it I repeated the above speed test for a TBImages copy and the result was 33 seconds as I would expect.
I've reverted back to the update 2 dos.library (don't like mixing components but FTPMount isn't compatible with the new one) - the YAM scanning folders on close thing is noticeably quicker with the old version so I tried this test again. Took about 2m30s, which isn't much different from before, so I think the test isn't showig the problem clearly.

I'm curious as to why it is much slower on my system though - DMA is definitely enabled. I have block size 512 and 600 buffers. My maxtransfer/mask values look completely wrong though so I'm going to try changing them.

(edit with revised maxtransfer I got it down to 2 mins)
Post Reply