citypw has joined #symbiflow
proteusguy has joined #symbiflow
kraiskil has joined #symbiflow
<nats`> litghost, I ran the tiles part in 15 minutes and the nodes part in 55 minutes
<nats`> without tinkering the ratio process blocksize we can do the 074 in 1h10min + few minutes for all file remerge
<nats`> is it a progress ?
citypw has quit [Ping timeout: 244 seconds]
kraiskil has quit [Ping timeout: 258 seconds]
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 258 seconds]
kraiskil has joined #symbiflow
<kgugala> @nats` we can discuss 07x fuzzers here, but I have a meeting in about 2 minutes I'll bbl
<nats`> no problem :)
<nats`> ttyl
<nats`> I'm at work too
<nats`> I started a run with a full 074 new version script
<nats`> let's see how long it take
proteusguy has quit [Quit: Leaving]
kraiskil has quit [Ping timeout: 245 seconds]
kraiskil has joined #symbiflow
<kgugala> at my side it finished
<kgugala> I'll push the fix
kraiskil has quit [Ping timeout: 272 seconds]
kraiskil has joined #symbiflow
<nats`> kgugala, I saw your new bug on the 074
<nats`> shoudl I do something in the new version or is it something solved by ignoring those net ?
<nats`> I didn't fix the working part of the 074
<nats`> the other point to check wouldbe to see if it's because of the 072 patch
<nats`> Command being timed: "python3 run_fuzzer.py"
<nats`> User time (seconds): 14816.12
<nats`> System time (seconds): 755.35
<nats`> Percent of CPU this job got: 346%
<nats`> Elapsed (wall clock) time (h:mm:ss or m:ss): 1:14:53
<nats`> Average shared text size (kbytes): 0
<nats`> Average unshared data size (kbytes): 0
<nats`> Average stack size (kbytes): 0
<nats`> Average total size (kbytes): 0
<nats`> Maximum resident set size (kbytes): 1201000
<nats`> Average resident set size (kbytes): 0
<nats`> Major (requiring I/O) page faults: 0
<nats`> Minor (reclaiming a frame) page faults: 35432521
<nats`> Voluntary context switches: 66357
<nats`> Involuntary context switches: 10470447
<nats`> Swaps: 0
<nats`> File system inputs: 11168
<nats`> File system outputs: 27366400
<nats`> Socket messages sent: 0
<nats`> Socket messages received: 0
<nats`> Signals delivered: 0
<nats`> Page size (bytes): 4096
<nats`> Exit status: 0*
<nats`> here is the runtime of the new version of the 074
<nats`> 1h14
<nats`> I'm wondering how long it take ont he current version
<nats`> uhhmm kgugala do yo uhave the csv from your zynq run ?
<nats`> I would like to know if it's normal to have a lot of NULL inside it
<kgugala> the bug is for 054
<kgugala> TBH I think that 054 is redundant
<kgugala> it runs the same tcl as 56
<nats`> oh yes sorry
<nats`> I red 074
<nats`> my bad
<kgugala> IMO we can drop 54 and use 56 to calculate those
<nats`> I didn't look at 05x serie
<kgugala> I'm testing this right now
<nats`> can you look in the csvoutput of the 074 ?
<kgugala> sure
<nats`> I have a lot of tile NULL
<nats`> but maybe that's ok
<nats`> filetype,subtype,filename
<nats`> tile,NULL,tile_NULL_X0Y156.json5
<nats`> tile,NULL,tile_NULL_X1Y156.json5
<nats`> tile,NULL,tile_NULL_X2Y156.json5
<nats`> tile,NULL,tile_NULL_X3Y156.json5
<nats`> tile,T_TERM_INT,tile_T_TERM_INT_X4Y156.json5
<nats`> tile,T_TERM_INT,tile_T_TERM_INT_X5Y156.json5
<kgugala> I have them too
<nats`> oky
<nats`> do you have a place to upload it ?
<kgugala> I may have
<nats`> I'm interested in having it to compare with my next run of zynq 074
<nats`> starting the zynq run of my new 074
<nats`> will let you know the time taken :)
<nats`> is there a good to make something like PR on github but only for testing before doing a real PR
<kgugala> nats`, you can always mark a PR as WIP
<kgugala> and use it for discussion
<nats`> ahhh sure !
<nats`> thanks
<nats`> I'll do that for the new version of 074
<nats`> I'll need to have people testing it
<nats`> kgugala,
<nats`> Work done !
<nats`> Command being timed: "python3 run_fuzzer.py"
<nats`> User time (seconds): 6608.01
<nats`> System time (seconds): 442.71
<nats`> Percent of CPU this job got: 361%
<nats`> Elapsed (wall clock) time (h:mm:ss or m:ss): 32:30.47
<nats`> Average shared text size (kbytes): 0
<nats`> Average unshared data size (kbytes): 0
<nats`> Average stack size (kbytes): 0
<nats`> Average total size (kbytes): 0
<nats`> Maximum resident set size (kbytes): 1020264
<nats`> Average resident set size (kbytes): 0
<nats`> Major (requiring I/O) page faults: 0
<nats`> Minor (reclaiming a frame) page faults: 31386362
<nats`> Voluntary context switches: 37120
<nats`> Involuntary context switches: 6036505
<nats`> Swaps: 0
<nats`> File system inputs: 71360
<nats`> File system outputs: 16468960
<nats`> Socket messages sent: 0
<nats`> Socket messages received: 0
<nats`> Signals delivered: 0
<nats`> Page size (bytes): 4096
<nats`> Exit status: 0
<nats`> I'm surprised it went really fast for the zyn
<nats`> zynq
<nats`> same csv file size
<nats`> good start
<nats`> by eye first and last lines are the same
<nats`> kgugala, are you interested that I push and PR that so you could test it ?
<kgugala> sure
<kgugala> you can tag me in the PR
proteusguy has joined #symbiflow
<nats`> kgugala, I'm running it from the directory with the makefile to be sure and them I push :)
<nats`> kgugala, I have an other problem with directory in 074 I think
<nats`> in generate_dump_after
_whitelogger has joined #symbiflow
<nats`> yep so that but it failed on my test because I didn't have it :)
<nats`> fixed like your PR and rerun :)
<nats`> s/so/saw/
<nats`> just output of the tcl script I made to fix (bad directory) and I should be good :)
<nats`> the final generation seems to work
<nats`> 2019-01-15 17:18:51.938046 Generating reduced tile for CLBLM_L
<nats`> 2019-01-15 17:18:51.938328 Using pool.imap_unordered
<nats`> 100% (600 of 600) |###################################################################################################################################################################################| Elapsed Time: 0:02:00 Time: 0:02:00
<nats`> 2019-01-15 17:21:10.662660 Generating reduced tile for CLBLM_R
<nats`> I think I'll try to do the same progress bar for the multithread version of fuzzer
<nats`> it's better than nothing or ton of line of text
powerbit has quit [Ping timeout: 272 seconds]
<nats`> the reducing stage is awfully long too !
<nats`> litghost, I think digshadow is right it's not possible to put 072 and 074 before other fuzzers... the 074 reduce stage is a nightmare
citypw has quit [Ping timeout: 250 seconds]
kraiskil has quit [Quit: Leaving]
<nats`> 2019-01-15 18:07:30.598128 Creating wire<->node index
<nats`> 100% (3824221077 of 3824221077) |#####################################################################################################################################################################| Elapsed Time: 0:00:59 Time: 0:00:59
<nats`> 100% (5153171150 of 5153171150) |#####################################################################################################################################################################| Elapsed Time: 0:01:00 Time: 0:01:00
<nats`> 2019-01-15 18:09:33.945337 Creating node tree
<nats`> 35% (398115 of 1122477) |############################################################# | Elapsed Time: 0:00:07 ETA: 0:00:15Traceback (most recent call last):
<nats`> File "create_node_tree.py", line 279, in <module>
<nats`> main()
<nats`> File "create_node_tree.py", line 271, in main
<nats`> if node in uphill_wire_node_index else [])))
<nats`> File "create_node_tree.py", line 103, in create_ordered_wires_for_node
<nats`> assert len(wires_in_node) >= len(all_wires)
<nats`> AssertionError
<nats`> 100% (1122477 of 1122477) |###########################################################################################################################################################################| Elapsed Time: 0:00:10 Time: 0:00:10
<nats`> something failed
<nats`> ...
<nats`> I guess I may need some help to sort that
<nats`> it seems to be unhappy of results of the 072 fuzzer and something else
<litghost> nats: Do put up the PR
<litghost> I'll take a look
<nats`> oky
<tpb> Title: WIP: reworking Fuzzer 074 for multi thread process - Dont MERGE ! by natsfr · Pull Request #526 · SymbiFlow/prjxray · GitHub (at github.com)
<nats`> PR pushed
<nats`> not for merging until we are sure :)
<nats`> ohhhh shit
<nats`> rubber ducky :D
<nats`> I think it fails because the 072 was generated for artix 7 and the 074 for zynq
<nats`> :D
<nats`> let me try
<litghost> ya, that'll totally bork it
<litghost> FYI WIP: in the title is enough to prevent a merge, so you don't need a giant "don't merge", that's what WIP means
<nats`> ah oky sorry
<nats`> I wante dot be sur e:)
<nats`> duuh
<nats`> I wanted to be sure
<nats`> I rerun a full 072/074
<nats`> but feel free to test :)
<nats`> do you remember how long is the 074 run ?
<litghost> I usually leave it overnight
<litghost> :/
<litghost> There is nothing in the processing that truely requires that length, it is just severly unoptimized
<litghost> Let's first fix the vivado leak per your PR, then maybe consider attacking the post-processing script. I believe it should be possible to speed it up significantly with only small modifications
<nats`> I didn't look into that
<nats`> but I was wondering if the json processing is optimized
<nats`> I have pretty bad souvenir of json lib
<nats`> but that was really long time ago
<nats`> anyway all the vivado processing for zynq take less than 50 minute for the 074
<nats`> and I started one with time to see the full process
<litghost> "but I was wondering if the json processing is optimized" -> Depends on what you mean. The json parsing library is reasonable fast, but problem I believe is some inefficient data passing methods. When I wrote the post-processing for 074, I proritized something working, so it isn't as clean as it might have been. Some profiling and refactoring would probably go a long way.
<nats`> I guess you'll be more efficient than me as you could see my python knowledge is long outdated now
<nats`> so performance wise..... :D
<litghost> reducing the runtime and memory usage of the vivado portion is of immediate benefit, so the PR is still very valuable
<nats`> sure sure :)
<nats`> and I'm happy to help on that
<nats`> uhhmmmmm got an idea !
<nats`> maybe I can make a bug report on that
<nats`> we should store in the run.ok the target of the last run !
<nats`> you would avoid stupid mistake like I made
<tpb> Title: Fuzzer storing last target · Issue #528 · SymbiFlow/prjxray · GitHub (at github.com)
<nats`> uhhhh litghost the post processing is about to blow my RAM away :D
<nats`> it seems it's really tight in 16GB
<litghost> nats: Ya, that seems about right
<litghost> I'm currently working on testing a couple INT pip CLs, and I'll move over to checking out your PR
<nats`> I'll try to get 16GB more next month
<nats`> it's too expensive for this one :D
<kgugala> nats`: I also started a 072/074 build
<nats`> oky
<nats`> with the PR ?
<nats`> and which target ?
<kgugala> artix
<kgugala> should I try zynq instead?
<nats`> oky
<nats`> nop
<nats`> should work on all
<nats`> the artix is longer
<nats`> zynq < artix < kintex
<kgugala> ok
<nats`> count about 30minute 072 for artix
<nats`> and I would say 1h15 074 BEFORE post processing
<nats`> I couldn't run the post proc
<nats`> I'm trying it for zynq right now
<nats`> I think we really have to stabilize all of that and generate as few as possible
<nats`> uhhmm how hard would it be to distribute the build over network
<nats`> there are python lib for that ?
<nats`> duhhh we really need to optimise the post processing
<nats`> it's awfully slow :D
<litghost> In general 072-074 weren't optimized because they are very deterministic, and don't need to be re-run often.
<litghost> This is unlike the other fuzzers which are fairly stochastic
<nats`> Traceback (most recent call last):
<nats`> File "generate_grid.py", line 676, in <module>
<nats`> File "generate_grid.py", line 578, in main
<nats`> main()
<nats`> with open(os.path.join(prjxray.util.get_db_root(), 'tilegrid.json')) as f:
<nats`> FileNotFoundError: [Errno 2] No such file or directory: '/home/nats/project/symbiflow/prjxray/database/zynq7/tilegrid.json'
<nats`> Makefile:16: recipe for target 'build/specimen_001/OK' failed
<nats`> make[1]: *** [build/specimen_001/OK] Error 1
<nats`> make[1]: Leaving directory '/home/nats/project/symbiflow/prjxray/fuzzers/074-dump_all'
<nats`> Makefile:20: recipe for target 'run' failed
<nats`> make: *** [run] Error 2
<nats`> Command exited with non-zero status 2
<nats`> Command being timed: "make run"
<nats`> User time (seconds): 17837.88
<nats`> System time (seconds): 1258.89
<nats`> Percent of CPU this job got: 305%
<nats`> Elapsed (wall clock) time (h:mm:ss or m:ss): 1:44:09
<nats`> Average shared text size (kbytes): 0
<nats`> Average unshared data size (kbytes): 0
<nats`> Average stack size (kbytes): 0
<nats`> Average total size (kbytes): 0
<nats`> Maximum resident set size (kbytes): 4110148
<nats`> Average resident set size (kbytes): 0
<nats`> Major (requiring I/O) page faults: 44
<nats`> Minor (reclaiming a frame) page faults: 659168440
<nats`> Voluntary context switches: 5940756
<nats`> Involuntary context switches: 10981805
<nats`> Swaps: 0
<nats`> File system inputs: 13773992
<nats`> File system outputs: 18203112
<nats`> Socket messages sent: 0
<nats`> Socket messages received: 0
<nats`> Signals delivered: 0
<nats`> Page size (bytes): 4096
<nats`> Exit status: 2
<nats`> ar sorry bad copy paste
<nats`> it failed at 1h44 -_-
<nats`> I think we really should do a sanity check before running
<nats`> ahhh I didn't run previous fuzzer
<nats`> :|
<tpb> Title: Fuzzer pre-run sanity check · Issue #529 · SymbiFlow/prjxray · GitHub (at github.com)
<nats`> oky I started a full run of all fuzzer from the main directory
<nats`> it'll run all night hopefully
<nats`> good night !
<nats`> uhhmm it stopped right before going to be
<nats`> I'll check that tmorrow
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow