|
u.2026 b.2025 v.2025/2026 (8 1st.2027) to 2027 N[2028] Q.21684 h.1013508 r.1013508 c.0.000kb s.1013508 d.2027 E.2027:1585544 M.1013507 L.1013776 est.128 0.000kb 0:43:17 3.348 peers.22/128 Q.(0 0)
|
|
|
|
But why does the fork have to make the existing outputs unspendable? I know it is possible to make any sort of fork, but who is proposing anything that would make these locktime tx unspendable?
The actual fork under discussion has this property. Restricting all transactions to 1MB would prevent the O(N 2) part of the hashing problem. Even better would be to restrict transactions to 100kB. As I understand it, core already considers transactions above 100kB as non-standard. The benefit of restricting transactions to 100kB should improve things by a factor of 100 (assuming O(N 2)). The problem with doing that is locked transactions. There could be a locked 200kB transaction that spends some outputs and where an alternative transaction can no longer be created (private keys lost and/or multisig outputs). A soft fork which restricted transactions to 100kB unless the height is evenly divisible by 100 would be a reasonable compromise here. Locked transactions can still be spent, but only in every 100th block. Mostly likely nobody has 100kB+ locked transactions anyway. if >100kb is nonstandard, then odds are very very high that there are no such pending tx and moving forward, CLTV can be used cool idea to have an anything goes block every 100, it probably isnt an issue but since it is impossible to know for sure, probably a good idea to have something like that, but for something that probably doesnt exist, then 1 in 1000 should be good enough, or just make it nonstandard and as long as any single miner is mining them it will eventually get confirmed. |
|
|
|
I am confused. In your example, it is in the blockchain and since you have the ability to spend it, then why would any fork make it so you cant spend it?
The spending transaction isn't in the block chain. You create transaction A and then create the refund transaction B. B is signed by both parties. A is submitted to the blockchain. B has a locktime of 2 years in the future. A soft fork happens that makes B unspendable for some reason. Perhaps, it requires signatures signed with the original private keys. In that case, it is impossible for either party to create the new spending transaction. This has already happened with the P2SH fork. If you happened to create a P2SH output, then it would be unspendable. On the plus side, I assume they actually checked that there were no such outputs when the fork was proposed. The key point is that a (chain of) timelocked transactions that are spendable now, should also be spendable in the future. I see, this was before CLTV, where future locktime tx couldnt be confirmed. Theoretically any unspent multisig output could be in this state, and any p2sh output could also have this issue. But why does the fork have to make the existing outputs unspendable? I know it is possible to make any sort of fork, but who is proposing anything that would make these locktime tx unspendable? |
|
|
|
From a practical point, if the amounts that are lost are small, then it could be solved via compensation. Practically speaking, it doesnt make sense to me to spend 1000 BTC of costs to make sure .001 BTC is preserved, assuming there are good justifications. But that's just me |
|
|
|
Regardless, of the realtime calc speed, I currently delay creation of a bundle until 10 blocks after the last block of that bundle and wanted to know what is the probability that it will need to be regenerated base on real world stats
As far as my node data, there have been only 2 instances of a reorg over 10 blocks, both due to significant unique events. 1 instance of a normal 6-block reorg. 2 instances of a 3 block reorg. 8 instances of a 2 block reorg. And lots of 1 block reorgs. 4 or more block reorgs are *extremely* rare. The standard client considers anything under 6 blocks to be unconfirmed. That seems like a good number to use for your purposes too. thanks for the confirmation. One additional nicety would be if the setback limit divides evenly into 2000. I guess it could be 8, but that doesnt conveniently add up to 2000. My plan is to have smaller bundles of 100 and 10, so at most there would be 19 mini-bundles of 100, 9 microbundles of 10 and 9 blocks for a total of 37 things to search through |
|
|
|
Anyway, other possible soft-fork changes that could prevent confirmation of a currently valid transaction include reduction of the block size limit (as Luke has been demanding), imposing a minimum output value (an antispam measure proposed by Charlie Lee), limtiing the number of inputs and outputs, extending the wait period for spending coinbase UTXOs, and many more
I remember seeing someone post a softfork that allowed to issue more than 21 million bitcoins, so clearly any sort of thing is possible via softfork/hardfork. Since a hardfork attack (or softfork) can always be attempted, it seems the only defense against something that is wrong is for there to be an outcry about it. James P.S. We can avoid the extreme N*N sig tx attack without breaking any existing tx by setting the limit to allow 1MB tx, but that still avoids problems from larger blocks |
|
|
|
Consider the standard refund transaction setup. A transaction with a 2 of 2 output is committed to the block-chain that is spent by a refund transaction.
If the refund transaction has a locktime 2 years into the future, then it cannot be spent for at least two years.
On the one hand, the refund transaction is unconfirmed. But on the other hand, there is no risk of its input being double spent. Both parties are safe to assume that the transaction will eventually be included.
A hard fork which makes the refund transaction invalid effectively steals that output. At the absolute minimum, there should be a notice period, but it is better to just not have that problem in the first place.
If someone has a 1MB transaction that spends a 2 of 2 output but is locked for 5 years, is it fair to say to them that it is no longer spendable?
I am confused. In your example, it is in the blockchain and since you have the ability to spend it, then why would any fork make it so you cant spend it? If you are saying there are some 1MB tx that has timelocked tx in the future that is already confirmed, I am not sure why that is relevant. Clearly all existing tx that are already confirmed would be grandfathered in. So the limit on tx size (however it is done) would apply to post fork tx. Sorry to be slow on this, but I dont see what type of unconfirmed tx we need to make sure it is valid post fork. If it requires to create a new spend that is less than a 1MB tx size, that doesnt lose funds, so I dont see the issue. |
|
|
|
Pre-signed but unbroadcast or unconfirmed transactions seem to be a tough problem.
I disagree on the "tough" part. In my opinion this is less difficult than DOSbox/Wine on Linux or DOS subsystem in Windows 32 (and Itanium editions of Windows 64). It is more of the problem how much energy to spend on scoping the required area of backward compatibility and preparing/verifying test cases. The initial step is already done in form of libconsensus. It is a matter of slightly broadening the libconsensus' interface to allow for full processing of compatibility-mode transactions off the wire and old-style blocks out of the disk archive. Then it is just a matter of keeping track of the versions of libconsensus. To my nose this whole "segregated witness as a soft fork" has a strong whiff of the "This program cannot be run in DOS mode" from Redmond, WA. Initially there were paeans written about how great it is that one could start Aldus Pagemaker both by typing PAGEMKR on the C> prompt (to start Windows) and by clicking PageMaker icon in the Program Manager (if you already had Windows started). Only years later the designers admitted this to be one of the worst choices in the history of backward compatibility. I agree |
|
|
|
Pre-signed but unbroadcast or unconfirmed transactions seem to be a tough problem.
...
TL;DR: Holding on to pre-signed transactions,without broadcasting them, seem to be a bad idea. There is no way to guarantee that a transaction will be confirmed, until it is confirmed. The older the transaction, the greater the risk of it becoming invalid.
maybe I am being a bit simplistic about this, but "unconfirmed" to me means that it hasnt been confirmed. So to require that all unconfirmed transactions must be confirmed contradicts the fundamental meaning of unconfirmed. What is the meaning of the word 'unconfirmed'? If all mempool tx that are unconfirmed, must be confirmed, then doesnt the confirmation point move to being accepted in the mempool? We would then need to say that all zeroconf tx in the mempool are actually confirmed? But if that is the case, then how can there be consensus about what tx are confirmed or not? If being in the mempool means its confirmed, we would need to enforce mempool consensus. Is that currently the case? Why is this a requirement? Is the whole point of blocks to have something to consensus on? I think things are difficult enough without requiring any solution to also treat unconfirmed tx as confirmed. |
|
|
|
Thanks! This really helps me find the math error in my analysis. I was missing the storks.
so we just need to wait stork number of blocks and that will be the optimal for mountain climbing.
I guess you think satoshi was an idiot too, as he said something about 10 blocks. Or was he committing fraud or whatever this crockpottery is.
ad hominem attacks vs. historical results with some actual math
And what exactly is this fraud you imply I am conducting? That using a hard coded lookup table (generated from p2p network and validated) instead of a DB is more efficient. Is that my supposed fraud?
James
I don't know. What I do know is that fraudster and gangsters (more generally common criminals) have exceptional sensitivity to being given "no respect" (cue Marlon Brando in The Godfather). Of course, correlation is not causation. But see how DeathAndTaxes reacted to the mention of money orders in 2012. I think that even he didn't know at that time what scam he's going to pull of years later. https://bitcointalk.org/index.php?topic=93655.msg1036760#msg1036760Your reaction to the mention of high-school-level science curriculum is very similar. Again, time will show. Are you seriously saying that since A -> B, if C -> B then C -> A can be concluded? Like: you wake up in the morning. criminals wake up in the morning. Therefore you are a criminal. or: you breathe air. criminals breathe air. Therefore you are a criminal. what is the name for this logic, I dont know about it and want to find out more. I know about transitive https://en.wikipedia.org/wiki/Transitive_relation when A -> B and B -> C that A -> C, but the reverse, this is quite novel. I guess if people operated as strict field elements with specific properties of reverse transivitism(?), maybe there is some basis for this, but last I checked I wasnt a finite field element. Are you? What is a bit frustrating is that you mix in some highly intelligent stuff with total nonsense, but I am just supposed to accept it all. otherwise I am like a fraudster or mobster? I dont ask for any respect that I dont deserve. If I make a logic error or math error, then point it out. make fun that I am a bad calculator, fine. But this nonsense attack by implication that is supported by absurd "logic", well maybe you are the one that needs to go to school? Maybe I need to be your teacher about some things. If you cant find any flaws with the logic or math, then you could just say that or be silent about it. James P.S. I have done most of my learning by using google to find relevant pages, so there are likely gaps in my knowledge as compared to someone who spent many years learning all the vital things that are learned in schools. |
|
|
|
If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction?
Seems like a no-brainer. I've been looking through the commits, but couldn't find it. I think classic has a defense along those lines. Even so, a 1 Mb transaction can still take a while to validate. A hypothetical scenario described here: https://bitcointalk.org/?topic=140078 states that a transaction of 1 Mb could take up to 3 minutes to verify. In reality, there was a roughly 1 Mb transaction that took about 25 seconds to verify described here: http://rusty.ozlabs.org/?p=522. Anything that is over a few seconds is quite a long time in computer standards. Now, both of those scenarios are less likely to happen now since libsecp256k1 introduced significantly faster signature validation, but it is still vulnerable to such attacks. A maliciously crafted 1 Mb transaction could, in theory, still take 25 seconds or longer to verify. The point is that I dont see any huge outcry if a tx is limited to say 1024 vins/vouts or some such number. If that avoids the N*N behavior it seems a simple way. On the non-malleable txid basis, I cant find issues with T. Nolan's approach and any need for internal lookup tables, is a local implementation matter, right? And should limitations of existing implementations constrain improving the protocol? just a question about tradeoffs. If the position is that anything that requires retooling the codebase to handle the increased load in the future is not acceptable, ok, just say so. After all, I dont want to be shamed again by suggesting that the current code isnt absolutely perfect in all ways possible. Just want to know what the groundrule are. If the current codebase is sacred then it changes the analysis of what is and isnt possible. Who am I to suggest making any code changes to the people that are 100x smarter than me. James |
|
|
|
I dropped out of kindergarten, I couldnt handle being shamed and put in the corner when I asked questions I wasnt supposed to.
Take mountain climbing as a hobby. Your main adversary will be then impersonal gravity. But you'll learn to deal with reality and how to overcome obstacles. Or you'll get yourself killed. Or you dont mind if people just categorize you as some type of troll? I would think a smart person would want his point of view appreciated and not just dismissed as troll blather.
I'm actually proud of getting called troll by now know fraudsters like DeathAndTaxes or shtylman. On you the question is still open: are you leaning more towards harmless crackpottery or towards willful fraud? We'll see. I appreciated your post about the getchaintips RPC, that was useful. Maybe you can stick to making useful posts? Like math based analysis, which is what I tried to do. Did I make any math errors?
This is public forum. I make post useful to the global audience of the readers, even if they aren't useful to you or any particular poster of any thread. Your math error is called: GIGO https://en.wikipedia.org/wiki/Garbage_in%2C_garbage_out . The mistake you are making is common enough that there's lots of educational texts regarding the "correlation vs. causation" issue. When I was in school profs used to refer to an excellent joke paper written by some Scandinavian scientists about presence of storks and childbirth rates in Scandinavia. I'm not sure if it was ever translated to English. Thanks! This really helps me find the math error in my analysis. I was missing the storks. so we just need to wait stork number of blocks and that will be the optimal for mountain climbing. I guess you think satoshi was an idiot too, as he said something about 10 blocks. Or was he committing fraud or whatever this crockpottery is. ad hominem attacks vs. historical results with some actual math And what exactly is this fraud you imply I am conducting? That using a hard coded lookup table (generated from p2p network and validated) instead of a DB is more efficient. Is that my supposed fraud? James |
|
|
|
With regards to the O(N2) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N2) performance assumes that the block contains a single transaction.
If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction? Seems like a no-brainer. I've been looking through the commits, but couldn't find it. I think classic has a defense along those lines. [/quote] Since I am supposed to not have a brain, it explains |
|
|
|
Why are you always using such harsh words? Maybe I am an idiot and you are super genius that is always right about everything.
I specifically limited my question to issues unrelated to software versions. just trying to understand things one piece at a time.
Now monsterer is saying it is always the same, you say it is probably going to increase. But I agree with you about the non PoW factors most likely dominating and since I am always wrong, does that mean you are wrong too?
You seem to have an excellent command of English for a non-native speaker. At the same time you seem to lack basic scientific education at the level of high school, where typically the "correlation vs. causation" is explained. In a previous thread you've exhibited 0/10 knowledge of basics of DBMS. I have no idea where you've received your education (home schooling? religious school?) but I haven't used any harsh words. I've used standard sentences that would be said by a teacher to a completely unprepared student face-to-face in any normal school. I'm not going to even delve into further scholastic experience like participating in competitive group sports or military training. I dropped out of kindergarten, I couldnt handle being shamed and put in the corner when I asked questions I wasnt supposed to. Rather than disprove how my analysis that 10 blocks is sufficient, you state that my analysis is bogus. So I should set it to 100 blocks? 1000 blocks? Some random number? That is your recommendation? Or maybe I should go to DBMS school since apparently without a DBMS Phd nothing I write has any validity. What does my education have to do with the analysis that 10 blocks appears to be sufficient? It might make others question your objectivity if you keep taking every chance to try to make me look stupid. Or you dont mind if people just categorize you as some type of troll? I would think a smart person would want his point of view appreciated and not just dismissed as troll blather. I appreciated your post about the getchaintips RPC, that was useful. Maybe you can stick to making useful posts? Like math based analysis, which is what I tried to do. Did I make any math errors? If the statistical model is dominated in the real world by non-PoW factors, then that is certainly an important issue and might need to be factored in. If so, what should the setback be? would 1 year be enough time to be sure? James |
|
|
|
Additionally, on further thought, it will still require twice the lookup tables. There needs to be one for the transactions that version 1 txs can spend from and one for the version 2 txs. Version 2 txs still need to be able to reference the txid of a version 1 tx to spend from it or that ntxid for the version 1 tx also needs to be stored somewhere so it will increase the lookup table sizes.
I meant if you want to refer to a version 2 transaction, you use the n-txid. The reason that this is ok is that legacy/timelocked transactions are automatically version 1, so it doesn't make locked transactions suddenly unspendable. Version 1 transactions would only refer to version 1 inputs (so no change) Version 2 transactions would use txid when referring to version 1 inputs and n-txid when referring to version 2 inputs. The nice feature of this is that n-txid don't need to recomputed back to the genesis block. It is a hard-fork though. I should have been clearer. Given that SW can achieve the same with a soft fork, I think SW wins here. Maybe SW should have happened in stages. The first stage could have been purely adding SW and no other changes (other than script versioning). Later script versions could add the new hashing rules. In fairness, they have been trying to keep feature creep to a minimum. With regards to the O(N 2) hashing operation. The transactions could simply have been limited to 1MB. This would have meant no changes at all. The O(N 2) performance assumes that the block contains a single transaction. If N squared performance assumes a single giant transaction, why not a rule to limit the size of a transaction? |
|
|
|
Sure, theoretically, but I dont like to just assume that the theory is precisely followed by reality.
My concern is with the practical. When did the ASIC's come out? That is a nonlinear increase in hashrate per amount of capital.
Yes I know the difficulty adjusts, but that is every 2016 blocks, there is a window of time where a technical leap increases the chance of larger reorg, but as time passes I think this chance is less and less.
Your analysis is bogus. Your are mistaking correlation with causation. The long term changes in the orphan rates are caused not by changes in hash rate but by changes in the number and connectivity of the mining pools. The number of pools decreased and the connectivity of the remaining pools improved. In particular Matt Corallo's Relay Network caused decrease in the orphan races. The probability of reorgs probably going to increase in the future due to the bugs in the competing implementations, due to DDoS attacks on the mining pool's infrastructure and due to Matt Corallo finally abandoning the maintenance of his Relay Network. The difficulty increase is just an innocent bystander. Why are you always using such harsh words? Maybe I am an idiot and you are super genius that is always right about everything. I specifically limited my question to issues unrelated to software versions. just trying to understand things one piece at a time. Now monsterer is saying it is always the same, you say it is probably going to increase. But I agree with you about the non PoW factors most likely dominating and since I am always wrong, does that mean you are wrong too? James |
|
|
|
and the hashrate was a small fraction back around block 225K. Not sure, but I think it is harder to reorg now vs then?
It was the same then as it is now - back then, network power was less than it is now, so although difficulty was lower than it is now, blocks were still 10 minutes each. Sure, theoretically, but I dont like to just assume that the theory is precisely followed by reality. My concern is with the practical. When did the ASIC's come out? That is a nonlinear increase in hashrate per amount of capital. Moving forward is it likely to have the same hashrate improvements was was possible a couple years ago. Not sure on the state of ASIC geometries, but if already the smallest practical geometry is being used, then it cant really get much more cost effective. Larger, yes, but with proportional cost for the silicon. Cleverer, yes, but possibly most of the low hanging fruit is already done Not sure the state of mining at block 225K, but given those factors it is possible that things are still exactly the same, but I am skeptical about that. What are the currently envisioned improvements in hashrate efficiency? Actually instead of just guessing, lets look at https://blockchain.info/charts/hash-rate?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=the alltime chart shows a definite slowdown of hashrate increase, so that does not seem the same to me. Granted from one block to the next, not much changes, but the discontinuity of new tech is what would create the temporary ability for a bigger reorg. 01/01/2010 18:15:05,0.006997468320659102 01/01/2011 18:15:05,128.16206770778084 18315x 2010 01/01/2012 18:15:05,8591.40080069935 67x 2011 01/01/2013 18:15:05,24291.440498714688 2.82x 2012 01/01/2014 18:15:05,11740802.089632047 483x 2013 01/01/2015 18:15:05,335365290.0920246 28.56x 2014 01/01/2016 18:15:05,697129166.4058079 2x 2015 As things went from CPU -> GPU -> FPGA -> ASIC and as market price is changing dramatically we see the change in hashrate vary from 18315x to 2x, so it does not seem safe to assume that things are the same. The 2014 gain was probably skewed by the bull market peak price bringing in a lot of new capital, but maybe that is around the same time ASIC made a big leap? The most likely way for an attack against bitcoin PoW seems to me for the creator of advanced tech to have a disproportionate hashrate per capital available, especially when efficiency gains are measured in the orders of magnitude. However, once the orders of magnitude technology gains are already done, it becomes a matter of much more "incremental" improvements of doubling per year. At least that is what I had guessed and the numbers indicate something similar to that. One way to look at this is back in 2013 what was the likelihood of a 500x hashrate increase? Was it really such a remote possibility? And what is the chance of a 500x hashrate increase now? Is there really any chance that next year we see 1,122,825 * 500 terahashes? or even 10x. Yes I know the difficulty adjusts, but that is every 2016 blocks, there is a window of time where a technical leap increases the chance of larger reorg, but as time passes I think this chance is less and less. James |
|
|
|
Are sigs in the witness data immune from malicious tx via lots of sigs?
I think they are since the transaction is hashed differently if the transaction uses witnesses. The different hashing method allows for faster hashes by using midstates which can be reused for every signature verification. well that's good, but would be nice to see it explicitly instead of having to assume. oh, thanks for the URL about segwit implementation, that helped me understand it a lot better James |
|
|
|
unless your node is special.
Standard PC running the default Linux client with basic cable modem connectivity. It's online probably 95% of the time, which would mean it could have missed a few reorgs. There could be an interesting story about that 6 block reorg. That does appear to be the biggest naturally occurring reorg. hopefully a few more long time nodes can post and we can get a much clearer idea. just having the second node confirm the 6 block reorg changes that from probable isolated node issue to a likely global reorg. and it wasnt that long ago, so the hashrate required would have been a lot. maybe it was during the DDOs attack? |
|
|
|
We could easily say SPV solves all signature attack problems. Just make it so your node doesnt do much at all and it avoids all these pesky problems, but the important issue to many people is what is the effect on full nodes. And by full, I mean a node that doesnt prune, relays, validates signatures and enables other nodes to do the bootstrapping.
Without that, doesnt bitcoin security model change to PoS level? I know how much you hate PoS
James
you paint the situation as if the binary options are 1. fully validating nodes (verify everything) and 2. thin clients (verify nothing). if we increase bandwidth pressure on nodes by increasing throughput capacity, then fully validating nodes can only switch to verifying nothing. a much better solution is one that allows for fully validating nodes that would otherwise be forced off the network to partially validate -- whether by relaying blocks only, validating non-segwit tx, pruning data that is already under significant proof of work and therefore very likely secure. just because a pruned node cant bootstrap a new node doesnt mean it doesnt provide great value to the network. are you suggesting that it would be better to simply force all these nodes off the network and into using trust-based protocols? because when you double bandwidth requirements and leave full nodes no other options, that's what happens. there is a new term for this: "tradeoff denialism"  one could claim that increasing throughput doesnt mean pressuring nodes to shut down. but youd be living in denial, as throughput is directly related to bandwidth requirements I am not saying that at all, but the question is if it is worth doubling the complexity of the code to process the blockchain, in order to have the intermediate "validates non-segwit tx" nodes. That appears to be the usecase that is created in this context. So I ask you, is it worth doubling the amount of code dealing with signing and wtxid calculations to be able to have nodes that cant see a new class of segwit tx? In fact, what good is that as they cant see these tx. That is my point. pruning nodes dont have a problem with HDD space now, so that is not an issue validating nodes are still going to have to validate the witness data, unless they dont upgrade and cant even see them. it just seems like a lot of work to get small benefit. Now if there was a new signature scheme that reduced the space required by 30% that comes with segwit, then it starts becoming like a tradeoff decision that can be made. Right now the tradeoff is a lot of extra complexity for slightly less tx capacity than 2MB HF, I think a bit more CPU load too as the wtxid needs to be calculated. I guess non-malleable txid is a good thing, but not including the signature in the txid calculation would achieve that too. The same segwit softfork trick can probably be used to surgically implement non-malleable signatures. I just sense a lot bigger attack surface for minimal immediate functionality gains, especially as compared to alternate possibilities. The following is test data from a test run I just did with iguana parallel sync: Time eth0
HH:MM:SS KB/s in KB/s out
02:16:09 33845.10 529.20
02:16:10 22049.13 451.58
02:16:11 11677.73 228.16
02:16:12 9593.46 455.37
02:16:13 6336.21 343.45
02:16:14 5547.12 253.51
02:16:15 5571.61 443.59
02:16:16 8923.98 284.75
02:16:17 4965.57 329.09
Time eth0
HH:MM:SS KB/s in KB/s out
02:16:18 2707.07 308.64
02:16:19 4556.55 531.37
02:16:20 23731.02 404.43
02:16:21 21888.67 578.04
02:16:22 34865.94 287.81
02:16:23 6858.57 84.74
02:16:24 7388.59 204.51
02:16:25 25366.26 358.41
02:16:26 14404.62 369.48
Time eth0
HH:MM:SS KB/s in KB/s out
02:16:27 4309.20 210.68
02:16:28 2171.04 131.02
02:16:29 6415.35 541.98
02:16:30 5755.03 229.80
02:16:31 2871.57 104.28
02:16:32 31940.83 336.98
02:16:33 9254.67 296.59
02:16:34 3870.30 127.04
02:16:35 2311.22 151.33
Time eth0
HH:MM:SS KB/s in KB/s out
02:16:36 40519.47 794.40
02:16:37 41520.63 599.23
02:16:38 20989.28 177.32
02:16:39 7380.14 119.51
02:16:40 3840.29 93.45
02:16:41 5518.21 273.35
02:16:42 21878.96 389.22
02:16:43 18944.35 205.19
02:16:44 8115.07 172.49
Time eth0
HH:MM:SS KB/s in KB/s out
02:16:45 5995.48 247.25
02:16:46 3898.50 89.55
02:16:47 8779.15 342.28
02:16:48 17804.29 220.64
02:16:49 17875.56 150.98
02:16:50 6362.67 97.60
02:16:51 12898.52 280.99
02:16:52 4688.76 118.78
02:16:53 30455.30 429.20
Time eth0
HH:MM:SS KB/s in KB/s out
02:16:54 22671.03 368.31
02:16:55 31944.43 453.90
02:16:56 15339.38 210.14
02:16:57 26194.08 392.04
02:16:58 32547.23 383.35
02:16:59 43963.34 403.81
02:17:00 56543.47 451.39
02:17:01 44521.50 393.46
02:17:02 15638.87 121.88
Time eth0
HH:MM:SS KB/s in KB/s out
02:17:03 4431.99 105.13
02:17:04 36061.83 437.45
02:17:05 21794.80 185.65
02:17:06 4929.13 92.09
02:17:07 48649.40 458.98
02:17:08 51054.86 405.49
02:17:09 46497.26 364.73
02:17:10 52669.18 430.47
02:17:11 57609.61 454.50
Time eth0
HH:MM:SS KB/s in KB/s out
02:17:12 53891.66 438.20
02:17:13 75635.86 893.06
02:17:14 30123.17 163.68
02:17:15 49683.16 444.59
02:17:16 47817.53 377.48
02:17:17 55363.33 461.86
02:17:18 43078.26 313.46
02:17:19 26149.84 278.79
02:17:20 6218.16 128.42
Time eth0
HH:MM:SS KB/s in KB/s out
02:17:21 18398.26 250.10
02:17:22 33918.31 325.32
02:17:23 11346.06 92.86
02:17:24 3202.43 19.64
02:17:25 2052.03 46.51
02:17:26 2337.96 71.44
02:17:27 2207.81 65.98
02:17:28 23519.14 304.05
02:17:29 55862.76 415.71
Time eth0
HH:MM:SS KB/s in KB/s out
02:17:30 47336.18 390.28
02:17:31 54468.87 494.74
02:17:32 56162.71 446.20
02:17:33 53209.51 359.89
02:17:34 49673.05 390.43
02:17:35 55885.92 390.03
02:17:36 53509.14 343.98
02:17:37 51986.69 342.46
02:17:38 45596.10 295.73
Time eth0
HH:MM:SS KB/s in KB/s out
02:17:39 14180.28 92.42
02:17:40 39211.49 352.47
02:17:41 63358.33 454.38
02:17:42 56712.67 422.91
02:17:43 28156.47 264.18
02:17:44 30555.58 259.53
02:17:45 56936.93 455.36
02:17:46 59813.32 418.80
02:17:47 59308.36 441.71
Time eth0
HH:MM:SS KB/s in KB/s out
02:17:48 59827.94 385.09
02:17:49 63606.64 430.43
02:17:50 59492.03 364.88
02:17:51 59679.47 427.00
02:17:52 51657.23 341.52
02:17:53 31356.31 240.92
02:17:54 55589.56 415.41
02:17:55 48241.90 359.84
02:17:56 52045.72 406.88
Time eth0
HH:MM:SS KB/s in KB/s out
02:17:57 16252.14 123.89
02:17:58 3553.59 26.32
02:17:59 5630.81 43.69
02:18:00 51815.96 464.66
02:18:01 47686.79 314.43
02:18:02 60419.80 424.08
02:18:03 46624.46 330.34
02:18:04 47545.23 424.62
02:18:05 47507.25 385.20
Time eth0
HH:MM:SS KB/s in KB/s out
02:18:06 47868.21 439.81
02:18:07 39462.08 344.86
02:18:08 47640.44 420.90
02:18:09 14381.75 143.29
02:18:10 5073.33 79.79
02:18:11 39820.47 392.17
02:18:12 16655.82 115.73
02:18:13 5446.54 171.00
02:18:14 34158.03 224.28
Time eth0
HH:MM:SS KB/s in KB/s out
02:18:15 7642.00 100.28
02:18:16 63972.90 510.19
02:18:17 54716.79 418.07
02:18:18 55642.69 412.52
02:18:19 57620.22 421.78
02:18:20 51703.89 357.54
02:18:21 55794.66 395.24
02:18:22 74435.85 493.97
02:18:23 69177.78 413.13
Time eth0
HH:MM:SS KB/s in KB/s out
02:18:24 35185.93 194.08
02:18:25 50689.11 370.72
02:18:26 54193.62 311.03
02:18:27 48325.34 334.62
02:18:28 40097.72 301.69
02:18:29 42524.21 348.53
02:18:30 29990.71 174.90
02:18:31 46417.99 393.07
02:18:32 49354.48 365.07
Time eth0
HH:MM:SS KB/s in KB/s out
02:18:33 49785.06 354.96
02:18:34 58241.59 397.50
02:18:35 40331.71 208.12
02:18:36 38532.94 306.23
02:18:37 59926.13 462.11
02:18:38 55388.72 457.29
02:18:39 51891.44 362.08
02:18:40 58160.40 407.42
02:18:41 56494.46 375.54
Time eth0
HH:MM:SS KB/s in KB/s out
02:18:42 58764.23 421.94
02:18:43 39135.91 299.46
02:18:44 54445.69 495.31
02:18:45 40178.11 275.20
02:18:46 9888.95 88.57
02:18:47 3974.48 60.40
02:18:48 5706.35 70.53
02:18:49 4687.59 50.77
02:18:50 2559.35 27.27
Time eth0
HH:MM:SS KB/s in KB/s out
02:18:51 1300.63 20.38
02:18:52 53046.86 440.35
02:18:53 57797.57 408.33
02:18:54 53286.55 358.68
02:18:55 47007.64 307.33
02:18:56 44760.59 392.78
02:18:57 44529.40 328.03
02:18:58 55051.48 427.69
02:18:59 16109.61 124.49
Time eth0
HH:MM:SS KB/s in KB/s out
02:19:00 64336.61 502.38
02:19:01 52468.14 306.32
02:19:02 55338.03 378.65
02:19:03 58055.49 387.75
02:19:04 33642.29 176.69
02:19:05 76283.29 658.32
02:19:06 26809.79 158.43
02:19:07 44293.91 285.87
02:19:08 16992.35 92.36
Time eth0
HH:MM:SS KB/s in KB/s out
02:19:09 7930.64 52.08
02:19:10 18896.54 172.51
02:19:11 65831.62 458.27
02:19:12 59365.14 385.31
02:19:13 55428.89 368.86
02:19:14 66314.21 423.40
02:19:15 61998.23 378.79
02:19:16 41052.71 218.75
02:19:17 64654.85 481.15
Time eth0
HH:MM:SS KB/s in KB/s out
02:19:18 48836.84 304.99
02:19:19 40473.96 294.56
02:19:20 78438.34 616.25
02:19:21 61219.32 220.61
02:19:22 68857.04 418.10
02:19:23 51494.45 328.57
02:19:24 61066.10 440.70
02:19:25 63359.72 403.87
02:19:26 61503.87 376.38
Time eth0
HH:MM:SS KB/s in KB/s out
02:19:27 52609.02 341.24
02:19:28 62605.62 344.72
02:19:29 33506.52 213.18
02:19:30 61961.18 425.11
02:19:31 58548.41 419.69
02:19:32 67196.68 459.66
02:19:33 58272.33 325.00
02:19:34 36245.20 161.49
02:19:35 49304.49 321.84
Time eth0
HH:MM:SS KB/s in KB/s out
02:19:36 69566.06 483.68
02:19:37 57570.63 257.62
02:19:38 30481.10 190.85
02:19:39 20689.72 120.54
02:19:40 9237.98 121.76
02:19:41 39236.86 279.72
02:19:42 86731.88 288.46
02:19:43 48629.80 156.77
02:19:44 26932.19 108.87
Time eth0
HH:MM:SS KB/s in KB/s out
02:19:45 21396.59 127.82
02:19:46 14506.07 95.55
02:19:47 34846.09 372.36
02:19:48 67259.36 376.53
02:19:49 50631.76 295.99
02:19:50 58821.97 373.39
02:19:51 35396.34 180.00
02:19:52 17401.16 146.28
02:19:53 15857.72 120.87
Time eth0
HH:MM:SS KB/s in KB/s out
02:19:54 55611.05 273.55
02:19:55 37599.18 151.61
02:19:56 48564.53 324.09
02:19:57 57451.85 290.47
02:19:58 54583.66 336.44
02:19:59 37948.65 169.34
02:20:00 48550.33 312.58
02:20:01 65724.29 423.13
02:20:02 60209.88 332.45
Time eth0
HH:MM:SS KB/s in KB/s out
02:20:03 74052.36 500.69
02:20:04 64638.80 359.71
02:20:05 29832.36 195.49
02:20:06 17762.60 215.73
02:20:07 16180.92 199.96
02:20:08 13248.35 110.94
02:20:09 8491.46 142.89
02:20:10 57840.12 429.11
02:20:11 41637.34 164.31
Time eth0
HH:MM:SS KB/s in KB/s out
02:20:12 22256.24 170.11
02:20:13 48529.94 397.18
02:20:14 62792.30 405.66
02:20:15 66254.80 484.94
02:20:16 67550.37 164.20
02:20:17 30034.56 109.21
02:20:18 23392.60 118.91
02:20:19 12935.04 152.88
02:20:20 72649.63 410.91
Time eth0
HH:MM:SS KB/s in KB/s out
02:20:21 50598.86 248.77
02:20:22 38862.75 258.64
02:20:23 57587.91 363.20
02:20:24 65281.96 305.90
02:20:25 34910.63 182.79
02:20:26 37640.38 208.30
02:20:27 40726.89 221.85
02:20:28 51446.10 304.25
02:20:29 57708.71 296.97
Time eth0
HH:MM:SS KB/s in KB/s out
02:20:30 56701.46 272.89
02:20:31 40277.95 242.45
02:20:32 60091.48 318.82
02:20:33 50029.19 340.54
02:20:34 51111.51 300.14
02:20:35 45111.85 261.23
02:20:36 64856.58 391.74
02:20:37 48861.61 217.04
02:20:38 43913.26 288.61
Time eth0
HH:MM:SS KB/s in KB/s out
02:20:39 61526.10 300.26
02:20:40 47306.20 217.89
02:20:41 39147.65 276.59
02:20:42 74420.89 731.66
02:20:43 39885.88 214.77
02:20:44 19364.66 157.79
02:20:45 45577.97 270.80
02:20:46 51020.70 335.66
02:20:47 70866.59 360.11
Time eth0
HH:MM:SS KB/s in KB/s out
02:20:48 62171.44 309.96
02:20:49 62204.88 344.18
02:20:50 61137.40 339.22
02:20:51 70663.35 376.55
02:20:52 55582.67 367.74
02:20:53 76263.89 400.27
02:20:54 63452.74 336.72
02:20:55 51701.00 225.72
02:20:56 44965.56 272.85
Time eth0
HH:MM:SS KB/s in KB/s out
02:20:57 62732.16 328.52
02:20:58 73721.37 631.83
02:20:59 51871.17 241.76
02:21:00 46303.93 198.11
02:21:01 32508.94 213.94
02:21:02 73284.92 433.73
02:21:03 49834.10 252.62
02:21:04 63456.48 325.10
02:21:05 58625.35 260.59
Time eth0
HH:MM:SS KB/s in KB/s out
02:21:06 35097.09 231.37
02:21:07 73310.38 379.32
02:21:08 61125.11 313.39
02:21:09 74764.18 536.69
02:21:10 58698.85 280.84
02:21:11 46448.25 176.45
02:21:12 59788.81 342.76
02:21:13 49127.29 286.97
02:21:14 61682.25 329.70
Time eth0
HH:MM:SS KB/s in KB/s out
02:21:15 50247.67 292.26
02:21:16 45406.79 258.51
02:21:17 67076.83 337.77
02:21:18 60259.81 314.62
02:21:19 56777.60 299.90
02:21:20 42174.36 233.22
02:21:21 53835.24 338.31
02:21:22 68306.79 394.66
02:21:23 53365.89 269.94
Time eth0
HH:MM:SS KB/s in KB/s out
02:21:24 57407.31 353.79
02:21:25 51447.38 240.82
02:21:26 46836.79 258.98
02:21:27 72469.32 692.14
02:21:28 37474.04 103.96
02:21:29 23530.95 108.24
02:21:30 16598.97 86.37
02:21:31 36923.23 290.40
02:21:32 67147.53 382.28
Time eth0
HH:MM:SS KB/s in KB/s out
02:21:33 61126.80 252.27
02:21:34 47133.20 220.84
02:21:35 65734.86 348.91
02:21:36 43444.24 192.81
02:21:37 55281.62 260.41
02:21:38 70902.61 345.20
02:21:39 61351.06 298.33
02:21:40 56973.40 255.57
02:21:41 63535.54 314.64
Time eth0
HH:MM:SS KB/s in KB/s out
02:21:42 62351.92 312.44
02:21:43 80183.78 482.16
02:21:44 35935.50 135.09
02:21:45 18757.51 121.89
02:21:46 10865.56 88.57
02:21:47 6301.87 116.73
02:21:48 59690.39 636.39
02:21:49 63399.55 348.95
02:21:50 48542.85 222.30
Time eth0
HH:MM:SS KB/s in KB/s out
02:21:51 36881.65 212.34
02:21:52 62972.36 373.64
02:21:53 54096.12 264.91
02:21:54 58251.50 322.55
02:21:55 60595.40 275.94
02:21:56 22283.33 179.93
02:21:57 10404.02 148.78
02:21:58 5238.00 123.95
02:21:59 4034.98 80.90
Time eth0
HH:MM:SS KB/s in KB/s out
02:22:00 3522.30 72.64
02:22:01 5469.38 50.20
02:22:02 7297.45 39.79
02:22:03 3099.11 54.25
02:22:04 3248.17 70.89
02:22:05 2913.00 71.76
02:22:06 2987.06 78.72
02:22:07 54645.86 255.73
02:22:08 61528.18 193.00
Time eth0
HH:MM:SS KB/s in KB/s out
02:22:09 35396.66 202.57
02:22:10 19741.68 120.61
02:22:11 15428.63 115.48
02:22:12 7972.73 89.96
02:22:13 9824.29 126.01
02:22:14 4874.94 138.29
02:22:15 3796.94 96.80
02:22:16 3575.66 71.28
02:22:17 6495.05 138.44
Time eth0
HH:MM:SS KB/s in KB/s out
02:22:18 9402.45 109.48
02:22:19 3968.94 58.29
02:22:20 3743.62 48.55
02:22:21 3694.58 91.52
02:22:22 39369.09 309.25
02:22:23 52195.56 270.83
02:22:24 65553.51 841.36
02:22:25 60596.64 308.53
02:22:26 49923.62 310.89
Time eth0
HH:MM:SS KB/s in KB/s out
02:22:27 38015.93 272.27
02:22:28 77433.58 397.76
02:22:29 43295.96 177.89
02:22:30 39624.80 352.38
02:22:31 76940.18 313.48
02:22:32 48802.54 239.23
02:22:33 42220.54 210.28
02:22:34 30216.32 209.80
02:22:35 19857.96 168.15
Time eth0
HH:MM:SS KB/s in KB/s out
02:22:36 19749.08 179.32
02:22:37 69007.84 383.16
02:22:38 62657.22 237.67
02:22:39 40278.10 182.12
02:22:40 29505.32 73.24
02:22:41 16779.58 80.06
02:22:42 13546.22 82.75
02:22:43 11332.97 115.06
02:22:44 9341.68 148.25
Time eth0
HH:MM:SS KB/s in KB/s out
02:22:45 7892.18 99.29
02:22:46 63716.31 436.78
02:22:47 65213.64 228.96
02:22:48 37110.78 239.34
02:22:49 24108.09 138.60
02:22:50 20563.37 188.07
02:22:51 85426.18 519.25
02:22:52 60595.63 166.00
02:22:53 34772.03 147.21
Time eth0
HH:MM:SS KB/s in KB/s out
02:22:54 20921.52 139.12
02:22:55 18048.99 91.69
02:22:56 14149.85 161.82
02:22:57 10498.95 165.25
02:22:58 45172.00 401.83
02:22:59 57405.60 189.23
02:23:00 23521.44 149.76
02:23:01 21669.55 189.22
02:23:02 16121.44 179.46
Time eth0
HH:MM:SS KB/s in KB/s out
02:23:03 77328.84 420.89
02:23:04 41386.30 227.66
02:23:05 25465.56 172.06
02:23:06 17135.39 170.74
02:23:07 7251.74 99.70
02:23:08 7156.27 135.40
02:23:09 6012.16 100.57
02:23:10 7197.49 79.37
02:23:11 31121.92 308.29
Time eth0
HH:MM:SS KB/s in KB/s out
02:23:12 49174.40 241.25
02:23:13 18126.57 193.59
02:23:14 8291.02 97.42
02:23:15 5704.04 130.39
02:23:16 5572.79 99.40
02:23:17 4238.67 51.94
02:23:18 23084.83 236.83
02:23:19 66062.94 301.79
02:23:20 69801.78 217.66
Time eth0
HH:MM:SS KB/s in KB/s out
02:23:21 42275.56 190.32
02:23:22 33421.54 175.13
02:23:23 23242.02 237.03
02:23:24 74739.70 589.49
02:23:25 48575.43 89.82
02:23:26 22961.87 110.47
02:23:27 16669.12 150.61
02:23:28 19389.75 190.22
02:23:29 12441.76 148.14
Time eth0
HH:MM:SS KB/s in KB/s out
02:23:30 9394.74 90.56
02:23:31 8814.92 107.57
02:23:32 10041.65 140.45
02:23:33 7615.92 81.05
02:23:34 4394.78 90.10
02:23:35 5058.33 97.70
02:23:36 17210.13 251.39
02:23:37 71479.65 599.75
02:23:38 36538.63 226.54
Time eth0
HH:MM:SS KB/s in KB/s out
02:23:39 23137.74 204.80
02:23:40 13405.63 106.80
02:23:41 11146.87 141.70
02:23:42 8407.14 132.03
02:23:43 6475.33 99.52
02:23:44 10320.05 84.66
02:23:45 8336.83 130.87
02:23:46 48163.20 298.63
02:23:47 28930.53 163.72
Time eth0
HH:MM:SS KB/s in KB/s out
02:23:48 13932.03 114.17
02:23:49 10571.42 109.56
02:23:50 9142.69 152.98
02:23:51 8345.02 104.82
02:23:52 5981.88 95.52
02:23:53 7646.74 144.23
02:23:54 63774.75 431.31
02:23:55 33982.19 128.44
02:23:56 11022.05 28.06
Time eth0
HH:MM:SS KB/s in KB/s out
02:23:57 11703.95 80.05
02:23:58 22302.66 159.12
02:23:59 10086.63 89.38
02:24:00 14350.75 97.90
02:24:01 34534.08 415.80
02:24:02 57772.03 299.37
02:24:03 36504.87 174.28
02:24:04 21607.46 159.68
02:24:05 63727.13 305.43
Time eth0
HH:MM:SS KB/s in KB/s out
02:24:06 41723.63 182.41
02:24:07 22508.25 120.39
02:24:08 36023.64 290.90
02:24:09 80853.44 276.29
02:24:10 68707.29 186.05
02:24:11 44681.10 103.14
02:24:12 30686.46 166.93
02:24:13 24367.32 166.80
02:24:14 23025.15 123.80
Time eth0
HH:MM:SS KB/s in KB/s out
02:24:15 16374.40 161.83
02:24:16 13540.23 181.54
02:24:17 55362.17 535.15
02:24:18 71284.66 273.90
02:24:19 39006.55 190.18
02:24:20 29352.29 161.27
02:24:21 19205.08 126.50
02:24:22 13631.40 96.25
02:24:23 13984.01 146.13
Time eth0
HH:MM:SS KB/s in KB/s out
02:24:24 11885.65 139.05
02:24:25 10765.22 89.47
02:24:26 9837.67 107.86
02:24:27 8067.06 99.33
02:24:28 7435.46 120.90
02:24:29 9676.53 164.67
02:24:30 11567.90 154.95
02:24:31 7071.66 139.11
02:24:32 7238.58 114.08
Time eth0
HH:MM:SS KB/s in KB/s out
02:24:33 7380.01 135.64
02:24:34 9878.01 115.30
02:24:35 6907.94 89.99
02:24:36 5678.94 101.34
02:24:37 5108.99 78.75
02:24:38 5603.92 93.55
02:24:39 10047.05 168.08
02:24:40 6253.95 87.87
02:24:41 9258.91 99.51
Time eth0
HH:MM:SS KB/s in KB/s out
02:24:42 5163.81 77.68
02:24:43 4742.32 76.61
02:24:44 4796.64 64.30
02:24:45 9213.41 152.15
02:24:46 5437.21 93.17
02:24:47 4815.19 53.38
02:24:48 4825.59 76.67
02:24:49 4778.73 98.66
02:24:50 8459.87 104.20
Time eth0
HH:MM:SS KB/s in KB/s out
02:24:51 5823.31 112.63
02:24:52 6333.90 63.41
02:24:53 6218.70 73.32
02:24:54 4303.65 77.32
02:24:55 4034.35 63.10
02:24:56 8541.50 105.18
02:24:57 66760.80 496.00
02:24:58 72990.92 226.50
02:24:59 70738.14 226.90
Time eth0
HH:MM:SS KB/s in KB/s out
02:25:00 48705.98 182.72
02:25:01 42352.30 195.52
02:25:02 35287.80 231.86
02:25:03 26577.77 196.54
02:25:04 26851.50 133.52
02:25:05 25732.53 211.39
02:25:06 50782.19 392.96
02:25:07 68746.20 183.96
02:25:08 40287.56 123.09
Time eth0
HH:MM:SS KB/s in KB/s out
02:25:09 29495.92 148.00
02:25:10 17260.72 114.26
02:25:11 30780.41 242.87
02:25:12 88400.50 204.73
02:25:13 53483.17 137.77
02:25:14 28357.99 88.91
02:25:15 20691.74 120.55
02:25:16 19874.62 155.95
02:25:17 27575.89 273.08
Time eth0
HH:MM:SS KB/s in KB/s out
02:25:18 87978.59 295.60
02:25:19 35152.23 112.75
02:25:20 22804.24 141.63
02:25:21 17659.70 131.40
02:25:22 17517.00 157.05
02:25:23 28606.48 219.29
02:25:24 12942.29 158.40
02:25:25 10937.27 111.85
02:25:26 10177.11 103.19
Time eth0
HH:MM:SS KB/s in KB/s out
02:25:27 12103.97 79.12
02:25:28 9957.51 95.22
02:25:29 8232.01 98.03
02:25:30 9091.32 88.95
02:25:31 7223.65 83.58
02:25:32 12675.62 140.81
02:25:33 12580.18 147.82
02:25:34 6441.42 57.97
02:25:35 6371.36 79.69
Time eth0
HH:MM:SS KB/s in KB/s out
02:25:36 4348.66 65.75
02:25:37 4983.48 125.04
02:25:38 92406.68 335.42
02:25:39 46378.26 138.67
02:25:40 29588.51 148.12
02:25:41 25718.35 164.80
02:25:42 19422.97 156.98
02:25:43 15440.77 214.03
02:25:44 73045.72 388.06
Time eth0
HH:MM:SS KB/s in KB/s out
02:25:45 45430.09 159.06
02:25:46 30190.29 65.52
02:25:47 21028.20 56.76
02:25:48 14713.18 106.88
02:25:49 15327.04 93.09
02:25:50 14247.42 89.77
02:25:51 14259.28 155.16
02:25:52 9251.41 131.32
02:25:53 55407.45 346.64
Time eth0
HH:MM:SS KB/s in KB/s out
02:25:54 65855.13 231.28
02:25:55 53515.27 286.13
02:25:56 74206.59 253.90
02:25:57 52763.92 175.76
02:25:58 41574.83 147.08
02:25:59 41699.50 158.14
02:26:00 31735.70 166.23
02:26:01 31175.74 206.41
02:26:02 42723.29 407.44
Time eth0
HH:MM:SS KB/s in KB/s out
02:26:03 84512.22 337.51
02:26:04 54827.23 114.76
02:26:05 45921.46 164.45
02:26:06 31283.68 145.32
02:26:07 32760.08 165.74
02:26:08 31279.24 214.17
02:26:09 32475.31 239.85
02:26:10 89632.01 511.55
02:26:11 65139.50 197.75
Time eth0
HH:MM:SS KB/s in KB/s out
02:26:12 45620.33 219.24
02:26:13 35992.47 181.68
02:26:14 20648.30 99.27
02:26:15 15937.25 110.60
02:26:16 88124.57 435.29
02:26:17 63627.90 170.19
02:26:18 42710.77 171.93
02:26:19 28587.40 153.24
02:26:20 19010.68 133.95
Time eth0
HH:MM:SS KB/s in KB/s out
02:26:21 15239.48 108.86
02:26:22 22261.42 240.48
02:26:23 90092.43 536.38
02:26:24 49668.56 119.64
02:26:25 29174.26 52.31
02:26:26 25523.14 120.71
02:26:27 21444.93 113.81
02:26:28 19039.51 105.05
02:26:29 20322.35 149.35
Time eth0
HH:MM:SS KB/s in KB/s out
02:26:30 16424.09 137.49
02:26:31 18055.73 194.58
02:26:32 93763.10 388.41
02:26:33 57006.67 199.86
02:26:34 38879.62 172.51
02:26:35 36929.73 148.98
02:26:36 20115.76 102.73
02:26:37 58781.17 467.04
02:26:38 81480.73 307.01
Time eth0
HH:MM:SS KB/s in KB/s out
02:26:39 66074.77 185.19
02:26:40 59093.21 183.04
02:26:41 47310.03 121.97
02:26:42 51759.69 138.47
02:26:43 41423.16 113.82
02:26:44 37384.89 163.40
02:26:45 37392.45 159.13
02:26:46 26169.71 108.32
02:26:47 28784.15 195.75
Time eth0
HH:MM:SS KB/s in KB/s out
02:26:48 17795.62 167.67
02:26:49 54385.83 358.89
02:26:50 71105.62 276.69
02:26:51 37402.86 153.60
02:26:52 31592.48 196.47
02:26:53 17890.61 140.24
02:26:54 16136.34 179.56
02:26:55 11446.82 120.61
02:26:56 14718.49 171.99
Time eth0
HH:MM:SS KB/s in KB/s out
02:26:57 42355.41 249.34
02:26:58 86458.75 236.69
02:26:59 56783.69 155.03
02:27:00 40061.02 163.69
02:27:01 24649.42 91.67
02:27:02 23326.01 131.48
02:27:03 17044.87 133.29
02:27:04 14990.12 112.46
02:27:05 18407.80 184.32
Time eth0
HH:MM:SS KB/s in KB/s out
02:27:06 51270.37 603.11
02:27:07 65746.89 276.98
02:27:08 48080.10 194.53
02:27:09 38869.17 170.04
02:27:10 27341.18 145.61
02:27:11 18631.65 92.26
02:27:12 37025.32 269.93
02:27:13 60984.46 214.34
02:27:14 44035.86 208.91
Time eth0
HH:MM:SS KB/s in KB/s out
02:27:15 24763.50 160.09
02:27:16 13202.80 102.59
02:27:17 19576.65 204.94
02:27:19 81949.20 642.30
02:27:20 72806.61 240.26
02:27:21 64690.11 207.83
02:27:22 50213.85 109.43
02:27:23 41497.78 140.43
02:27:24 42515.89 209.17
Time eth0
HH:MM:SS KB/s in KB/s out
02:27:25 42461.82 174.10
02:27:26 33700.94 168.96
02:27:27 32869.52 107.41
02:27:28 32631.54 178.13
02:27:29 32576.31 174.30
02:27:30 26762.37 183.74
02:27:31 57654.24 511.36
02:27:32 69653.15 204.22
02:27:33 61301.35 205.36
Time eth0
HH:MM:SS KB/s in KB/s out
02:27:34 45061.74 151.23
02:27:35 35339.93 192.41
02:27:36 22439.62 146.83
02:27:37 15462.09 54.75
02:27:38 12528.15 35.61
02:27:39 12627.45 50.99
02:27:40 11996.36 69.41
02:27:41 13510.10 104.68
02:27:42 23204.21 198.36
Time eth0
HH:MM:SS KB/s in KB/s out
02:27:43 15943.04 114.33
02:27:44 15076.80 118.37
02:27:45 10156.39 103.00
02:27:46 10422.15 135.71
02:27:47 12266.09 160.72
02:27:48 10922.82 145.37
02:27:49 12585.87 138.00
02:27:50 68289.63 352.15
02:27:51 60807.79 316.21
Time eth0
HH:MM:SS KB/s in KB/s out
02:27:52 27762.34 188.39
02:27:53 20117.07 121.86
02:27:54 16655.50 115.44
02:27:55 13659.23 92.88
02:27:56 19868.94 160.38
02:27:57 11453.97 70.56
02:27:58 13390.40 140.28
02:27:59 13240.90 113.21
02:28:00 12676.01 130.32
Time eth0
HH:MM:SS KB/s in KB/s out
02:28:01 46915.90 450.36
02:28:02 79553.08 654.74
02:28:03 60601.54 201.73
02:28:04 38376.10 187.34
02:28:05 30453.17 121.40
02:28:06 24634.53 168.62
02:28:07 20460.96 147.03
02:28:08 17133.40 130.35
02:28:09 14220.38 124.35
Time eth0
HH:MM:SS KB/s in KB/s out
02:28:10 10983.89 102.29
02:28:11 27313.08 280.75
02:28:12 18886.11 178.06
02:28:13 11207.46 83.74
02:28:14 11177.55 117.12
02:28:15 5971.50 26.64
02:28:16 7536.95 87.90
02:28:17 7659.23 116.48
02:28:18 13167.34 157.62
Time eth0
HH:MM:SS KB/s in KB/s out
02:28:19 8856.75 101.46
02:28:20 21839.90 249.04
02:28:21 21634.76 162.16
02:28:22 8565.96 103.46
02:28:23 7898.29 90.00
02:28:24 8704.44 101.95
02:28:25 7062.73 76.78
02:28:26 6465.20 124.62
02:28:27 17367.24 171.61
Time eth0
HH:MM:SS KB/s in KB/s out
02:28:28 25245.66 196.62
02:28:29 8433.70 95.78
02:28:30 10175.92 52.76
02:28:31 8664.96 105.04
02:28:32 9006.16 95.31
02:28:33 5879.33 61.66
02:28:34 6918.05 65.44
02:28:35 10965.66 142.49
02:28:36 72947.28 739.04
Time eth0
HH:MM:SS KB/s in KB/s out
02:28:37 73678.01 251.98
02:28:38 58886.80 166.31
02:28:39 32432.21 107.33
02:28:40 78547.68 381.96
02:28:41 67963.51 176.46
02:28:42 62552.06 148.66
02:28:43 55239.48 108.44
02:28:44 37857.05 112.51
02:28:45 34437.72 105.14
Time eth0
HH:MM:SS KB/s in KB/s out
02:28:46 25011.91 104.95
02:28:47 17379.54 83.65
02:28:48 15233.39 91.98
02:28:49 13980.90 72.06
02:28:50 13755.29 109.45
02:28:51 12014.07 99.72
02:28:52 16094.17 115.84
02:28:53 13651.72 73.71
02:28:54 10630.23 75.37
Time eth0
HH:MM:SS KB/s in KB/s out
02:28:55 7998.11 89.25
02:28:56 8803.32 56.79
02:28:57 57358.63 527.10
02:28:58 70942.49 256.42
02:28:59 63205.96 249.50
02:29:00 72486.67 262.17
02:29:01 63630.54 191.47
02:29:02 59942.47 146.56
02:29:03 44194.05 125.04
Time eth0
HH:MM:SS KB/s in KB/s out
02:29:04 40216.38 132.22
02:29:05 33787.09 144.08
02:29:06 28827.74 132.45
02:29:07 60555.25 504.04
02:29:08 77544.44 414.35
02:29:09 66796.80 138.28
02:29:10 53373.66 142.60
02:29:11 42884.18 115.80
02:29:12 37071.29 137.86
Time eth0
HH:MM:SS KB/s in KB/s out
02:29:13 28247.28 128.57
02:29:14 25520.22 132.26
02:29:15 24315.78 158.61
02:29:16 19461.36 83.62
02:29:17 19127.17 115.54
02:29:18 17749.41 95.44
02:29:19 19925.15 126.07
02:29:20 18659.55 104.82
02:29:21 14946.88 95.89
Time eth0
HH:MM:SS KB/s in KB/s out
02:29:22 16163.44 132.98
02:29:23 16052.21 92.71
02:29:24 13242.81 92.66
02:29:25 14759.39 146.26
02:29:26 16566.62 192.35
02:29:27 15025.01 136.54
02:29:28 10528.31 104.79
02:29:29 10886.05 123.11
02:29:30 8513.08 122.78
Time eth0
HH:MM:SS KB/s in KB/s out
02:29:31 8631.74 80.31
02:29:32 9103.51 144.35
02:29:33 14163.01 175.80
02:29:34 40962.72 493.84
02:29:35 93048.32 665.11
02:29:36 66424.20 261.16
02:29:37 59000.29 199.75
02:29:38 37862.25 117.94
02:29:39 36531.98 150.34
Time eth0
HH:MM:SS KB/s in KB/s out
02:29:40 40262.95 147.31
02:29:41 30986.46 173.52
02:29:42 24124.62 163.99
02:29:43 18995.60 149.74
02:29:44 16674.01 154.58
02:29:45 19638.81 180.11
02:29:46 13889.63 129.72
02:29:47 12060.11 120.22
02:29:48 12496.54 148.26
Time eth0
HH:MM:SS KB/s in KB/s out
02:29:49 14630.61 136.88
02:29:50 44890.28 339.14
02:29:51 80303.43 774.34
02:29:52 74545.47 283.52
02:29:53 65714.89 220.00
02:29:54 62666.76 173.67
02:29:55 62347.10 148.69
02:29:56 56790.12 140.29
02:29:57 61189.43 161.03
Time eth0
HH:MM:SS KB/s in KB/s out
02:29:58 61268.59 133.26
02:29:59 52569.67 104.14
02:30:00 48180.98 117.89
02:30:01 45463.79 133.40
02:30:02 42118.19 175.73
02:30:03 33361.92 122.04
02:30:04 30977.12 153.76
02:30:05 26376.39 193.59
02:30:06 24151.89 140.94
Time eth0
HH:MM:SS KB/s in KB/s out
02:30:07 27859.65 217.03
02:30:08 17074.16 141.67
02:30:09 17341.53 88.21
02:30:10 13711.81 66.33
02:30:11 14031.88 120.92
02:30:12 18071.87 127.80
02:30:13 10958.72 94.88
02:30:14 50175.89 403.47
02:30:15 22650.31 140.84
Time eth0
HH:MM:SS KB/s in KB/s out
02:30:16 12285.94 103.64
02:30:17 15057.09 141.00
02:30:18 13864.30 124.51
02:30:19 14038.04 113.00
02:30:20 9788.40 85.55
02:30:21 14167.05 77.27
02:30:22 9607.41 84.15
02:30:23 11463.11 79.88
02:30:24 7735.19 101.06
Time eth0
HH:MM:SS KB/s in KB/s out
02:30:25 9898.37 118.44
02:30:26 8772.24 95.22
02:30:27 13057.54 144.44
02:30:28 9840.82 108.84
02:30:29 15310.92 140.55
02:30:30 56621.52 481.95
02:30:31 19301.80 144.23
02:30:32 47218.27 584.58
02:30:33 66724.63 273.51
Time eth0
HH:MM:SS KB/s in KB/s out
02:30:34 57402.13 180.79
02:30:35 53781.58 177.28
02:30:36 42859.96 148.14
02:30:37 25829.27 115.08
02:30:38 23305.98 164.23
02:30:39 23254.84 139.58
02:30:40 25676.02 176.34
02:30:41 14714.19 106.36
02:30:42 18272.70 147.78
Time eth0
HH:MM:SS KB/s in KB/s out
02:30:43 10789.26 91.34
02:30:44 12355.84 83.97
02:30:45 8252.45 80.12
02:30:46 13603.73 157.97
02:30:47 8984.21 124.46
02:30:48 10610.11 118.70
02:30:49 49534.84 659.56
02:30:50 69002.60 406.49
02:30:51 55594.60 232.67
Time eth0
HH:MM:SS KB/s in KB/s out
02:30:52 58367.57 263.09
02:30:53 51598.79 197.92
02:30:54 52928.29 257.74
02:30:55 66857.27 357.13
02:30:56 80847.42 463.30
02:30:57 49054.93 212.40
02:30:58 32558.85 167.15
02:30:59 19084.98 99.73
02:31:00 15713.44 101.56
Time eth0
HH:MM:SS KB/s in KB/s out
02:31:01 17505.31 146.00
02:31:02 18007.33 183.57
02:31:03 21844.09 224.65
02:31:04 21458.43 202.42
02:31:05 20377.77 205.40
02:31:06 16818.59 138.02
02:31:07 17066.45 157.10
02:31:08 18720.30 202.31
02:31:09 51725.16 484.95
Time eth0
HH:MM:SS KB/s in KB/s out
02:31:10 18991.26 150.26
02:31:11 10827.27 131.27
02:31:12 8537.31 106.34
02:31:13 8285.83 103.56
02:31:14 11360.60 162.70
02:31:15 74303.56 673.62
02:31:16 72552.23 288.89
02:31:17 65030.57 192.44
02:31:18 47718.31 153.97
It created a readonly data set that is compressible to less than 20GB and has 35GB of sig data in a separate directory. So the sig data can be deleted after it is verified, or with a bit more work, you can just skip it if you are willing to rely on checkpoint. then you can get a 20GB bandwidth used for a full sync (without sigs). Still not fully optimized, but mostly processing at close to full resource utilization. I am not saying others havent done this too, all I am saying is that I have and maybe my experience is useful to some people who want to hear a different point of view than the party line. v.129/129 (2000 1st.129) to 201 N[202] Q.70 h.402000 r.258000 c.0.000kb s.377583 d.129 E.129:452552 M.403286 L.403287 est.119 0.000kb 0:32:42 2.905 peers.83/256 Q.(0 0) downloaded 377583 blocks, fully processed 258000 in 0:32:42 James |
|
|
|
|
Show Posts
