• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Suggestion for users of the Round Robin/ Mika pproxy.

J

Jator

Golden Member
One of the major complaints lately has been the size of the blocks comming through to the clients. Contrary to popular belief, the pproxies cannot control what size blocks it gets or gives out. The best way to help ensure that you will get the largest block possible is to set the block size to the largest number, 33^.

This means not only are you requesting the largest block available, but you are also not splitting up larger blocks to give you a smaller block. If someone has their client set to 28-32, then if the pproxy is at a 33^ block, it has to split the block to give you the size you requested. This leads to producing a lot of smaller blocks that end up getting dispursed out as well.

I have set all my clients to fetch 33^ block size, and I also have it fetch block counts in divisible of 32. Thus I select to recieve 32,64,96 or higher.

If we can get a lot of people to follow this guideline, I think we can help reduce the number of smaller blocks being dispursed.
 
Jay-

I have all my clients set to 33^, but my average block size over the last 2 months is a whopping 4*2^28 :Q

I even updated a machine that recieved nothing but 1*2^28 blocks.. 1999 of them. :Q

Hopefully this doesn't cause too many problems, as I know it takes 2^28 times longer to download blocks one at a time than it does download them 32 at a time. 😉

SD
 
Jay has a very good point. Using a larger block size reduces load on the network, and on all the servers which handle the blocks. It is highly recommended to use as large a block size as possible.

Mika
 
There's something here I hadn't thought of :
all my clients are set to fetch 2^33, or (32*2^28) blocks whenever available. but I had left the fetch threshold to default, as fetch-workunit-threshold=0, wich currently means 24 blocks. So I never got 32 block packets, even though there were some in my proxy.

so in addition to putting preferred-blocksize=33 in the [rc5] section of dnetc.ini, I'd advise to also set fetch-workunit-threshold=32, or any 32 multiple like Jay said.

doing this here right now ; )
 
and, Russ, have you updated your "quick install" floppies yet?

This sounds like a good thing.
 
If you do update the floppy distro. Russ, make sure that you mention that a block will now take a little (much :Q based on 2^28 size) longer to do, but the real work output will be the same....🙂
 
Ok, so under the [RC5] heading, what are the settings that I should have that are best for the proxies and for DNET (and for my network!)??

Here is what I currently have

[rc5]
randomprefix=218
preferred-blocksize=33
fetch-workunit-threshold=480

15x32=480


That sound about right?

-Skaven
 
Skaven:

Yup, that's a nice way of doing it! 😎

Jay:

Thanks for the suggestion... I followed it the first time I read this thread, just forgot to say thanks for the reminder! :Q

THANK YOU!

With love and respect your fellow TA member

Two-Face

/edit I can't speeeel! 🙁
 
Umm, i'm not very sure. can anyone state the status and what's the purpose of the Round Robin? How's it setup and how to join? What's it for?
 
TA Proxy Status

This is where you can go to look up the status of the baby bovines. Simply put, these are in place to provide redundency in case one or more of the bovines goes out temporarily.

Jay
 
jinsonxu

Simply put, the round robin acts as sort of proxy redirector. You tell the Dnet client to flush to proxy.teamanandtech.com (the rr) and this then directs that to one of the TA pProxies running - list in above post.
It helps to reduce load on just the one proxy.
 
I don't think the client will automatically request a "smaller" block to come in under the buffer limit. For instance, I have a computer at work that buffers 2000 blocks. After a flush, it will often have more than 2000 (such as 2012) because the last block was larger than the exact size that would have made it 2000. So, I don't think you need to worry about the buffer size setting as much as the block size setting. ALWAYS set it to 33^.

JHutch
 
jinsonxu,

After I originally brought the tappstatus page online, I was considering letting other pproxy operators get listed (in a general TA pproxy section (including public and private pproxies)). I haven't acted upon the idea yet, but now that you bring it up, I will add the few lines of coding it takes to do it. A new and very cool feature will be added very soon and you might want to be part of it. 🙂

If other pproxy operators would like to have their pproxy status listed on the tappstatus page, please contact me via email (in profile). I must note that the usage of the general TA pproxies will probably not be used in the RR chain. There's no hard reason for this, other then because seven pproxies are already in rotation.

BTW, you can thank Jator for having such an evil dynamic IP (I grumbled quite a few times 🙂 ). The database fully supports dynamic IP switching as of a couple weeks ago.

Brad..
 
hehe....

Brad,

Sorry, Road Runner and my power company conspire against me. Every other day, one goes out, then 2 days later, the other. Not sure how I got on their sh!t list, but I am. 😉

Hopefully some time in December I will switch to Telocity and will have a static IP. Then jator.2y.net will become simply jator.net.

Jay
 
Jator,

It doesn't affect me anymore.... 🙂 Check out the tappstatus page and you may be able to figure it out. It's all automatic...

Brad..

 
Brad,

I figured you automated the process. I notice it still takes about a day for the round robin to start sending me blocks when I change my ip address. Figured its the DNS server taking the longest to update its table.

Jay
 
Well actually Jay, updating of the DNS entries was always manual (which is why I was grumbling. 🙂 ). As of an hour ago, the process is fully automated. The tappstatus knew when you changed IP's, shade your entry to blue, and then wait for me to notice it. At which point I would manually update the RR. Now tappstatus will generate a new zone file and update the RR automagically.

I'm not sure if you noticed the "other" feature that was brought online. A couple entries on tappstatus are now showing it. 🙂 I'm impressed. 🙂

Oh, and now if you change IP's and run sendstatus, the RR will reflect your new IP in under two hours (if not sooner).

Brad..
 
You must log in or register to reply here.
Back
Top