Two thoughts: 1. That field used to be in the DB, but was taken out because it was too big for some reason. It made the user's web page too big, a log too big, whatever; I don't remember exactly.
2. You have to send the info back each time anyway because these things change all the time. Last week one of my mobos failed. The two GTX 460 GPUs replaced two 250 GPUs in another machine, the 950 CPU replaced a 920 in another computer, and I put my spare mobo and CPU into S&H service. The machine names are the same, the WUs are the same, everything is the same except the subject data is different for three machines. The only possible improvement I can think of is to hash the data and send the hash and the data whenever the hash changes. You would have to have a good hash function for stirngs. 3. From a scientific point of view the data would be really nice to have. Charles Elliott > -----Original Message----- > From: boinc_dev [mailto:[email protected]] On Behalf > Of Jon Sonntag > Sent: Friday, August 23, 2013 9:12 AM > To: David Anderson > Cc: BOINC Developers Mailing List @berkeley.edu > Subject: Re: [boinc_dev] android -- boinc not storing cpu features > (/proc/cpuinfo features) > > If not in the database, the 1024 characters of CPU info gets sent every > single time the host contacts the server using network bandwidth over > and > over and over and over and over and over.... What costs more, a GB of > disk > space or a GB of bandwidth? (Hint: It isn't disk space.) > > Jon Sonntag > > > On Thu, Aug 22, 2013 at 7:08 PM, David Anderson > <[email protected]>wrote: > > > We could do this, but it would require adding a 1024-character > > field to the host DB table, which would increase the DB size somewhat > > (e.g. by 1 GB for projects w/ 1M hosts). > > Probably not worth it. > > > > On 22-Aug-2013 3:14 PM, Carl Christensen wrote: > > > >> it might be nice on the boinc project's web page for computer (as > Bernd > >> mentioned) to print the p_feature field (like we do for bencharks)? > plus > >> the > >> "coprocessor" line I was thinking "ARM Neon" & VFP counted as a > >> coprocessor > >> (FPU rather than GPU)! ;-) ______________________________** > >> _________________ > >> boinc_dev mailing list [email protected] > >> > http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_dev<http://lists > .ssl.berkeley.edu/mailman/listinfo/boinc_dev>To unsubscribe, > >> visit the above URL and (near bottom of page) enter your email > address. > >> > >> ______________________________**_________________ > > boinc_dev mailing list > > [email protected] > > > http://lists.ssl.berkeley.edu/**mailman/listinfo/boinc_dev<http://lists > .ssl.berkeley.edu/mailman/listinfo/boinc_dev> > > To unsubscribe, visit the above URL and > > (near bottom of page) enter your email address. > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
